<?xml version="1.0" encoding="UTF-8"?>
<rfc-index xmlns="https://www.rfc-editor.org/rfc-index" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="https://www.rfc-editor.org/rfc-index 
                               https://www.rfc-editor.org/rfc-index.xsd">
    <bcp-entry>
        <doc-id>BCP0001</doc-id>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0002</doc-id>
    </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>
            <doc-id>RFC6996</doc-id>
            <doc-id>RFC7300</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>
            <doc-id>RFC5657</doc-id>
            <doc-id>RFC6410</doc-id>
            <doc-id>RFC7100</doc-id>
            <doc-id>RFC7127</doc-id>
            <doc-id>RFC7475</doc-id>
            <doc-id>RFC8789</doc-id>
            <doc-id>RFC9282</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0010</doc-id>
        <is-also>
            <doc-id>RFC8713</doc-id>
            <doc-id>RFC9389</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0011</doc-id>
        <is-also>
            <doc-id>RFC9281</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0012</doc-id>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0013</doc-id>
        <is-also>
            <doc-id>RFC4289</doc-id>
            <doc-id>RFC6838</doc-id>
            <doc-id>RFC9694</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0014</doc-id>
        <is-also>
            <doc-id>RFC2119</doc-id>
            <doc-id>RFC8174</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>
            <doc-id>RFC3934</doc-id>
            <doc-id>RFC7776</doc-id>
            <doc-id>RFC8716</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0026</doc-id>
        <is-also>
            <doc-id>RFC8126</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>RFC7595</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>
            <doc-id>RFC5237</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>
            <doc-id>RFC9283</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0040</doc-id>
        <is-also>
            <doc-id>RFC7720</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0041</doc-id>
        <is-also>
            <doc-id>RFC2914</doc-id>
            <doc-id>RFC7141</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0042</doc-id>
        <is-also>
            <doc-id>RFC6895</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>RFC9245</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>RFC4647</doc-id>
            <doc-id>RFC5646</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>RFC5771</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>RFC7154</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>RFC9205</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0057</doc-id>
        <is-also>
            <doc-id>RFC9778</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>RFC4520</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0065</doc-id>
        <is-also>
            <doc-id>RFC3405</doc-id>
            <doc-id>RFC8958</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0067</doc-id>
        <is-also>
            <doc-id>RFC5727</doc-id>
            <doc-id>RFC7957</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>
            <doc-id>RFC9416</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>RFC5378</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0079</doc-id>
        <is-also>
            <doc-id>RFC8179</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>
            <doc-id>RFC8704</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>
            <doc-id>RFC9599</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>RFC5742</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>
    </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>
            <doc-id>RFC4897</doc-id>
            <doc-id>RFC8067</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>RFC7120</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0101</doc-id>
        <is-also>
            <doc-id>RFC8711</doc-id>
            <doc-id>RFC8714</doc-id>
            <doc-id>RFC8717</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>
    <bcp-entry>
        <doc-id>BCP0105</doc-id>
        <is-also>
            <doc-id>RFC4085</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0106</doc-id>
        <is-also>
            <doc-id>RFC4086</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0107</doc-id>
        <is-also>
            <doc-id>RFC4107</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0108</doc-id>
        <is-also>
            <doc-id>RFC4148</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0109</doc-id>
        <is-also>
            <doc-id>RFC4159</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0110</doc-id>
        <is-also>
            <doc-id>RFC4170</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0111</doc-id>
        <is-also>
            <doc-id>RFC4181</doc-id>
            <doc-id>RFC4841</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0112</doc-id>
        <is-also>
            <doc-id>RFC4222</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0114</doc-id>
        <is-also>
            <doc-id>RFC4384</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0115</doc-id>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0116</doc-id>
        <is-also>
            <doc-id>RFC4446</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0117</doc-id>
        <is-also>
            <doc-id>RFC4497</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0118</doc-id>
        <is-also>
            <doc-id>RFC4521</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0119</doc-id>
        <is-also>
            <doc-id>RFC4579</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0120</doc-id>
        <is-also>
            <doc-id>RFC4608</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0121</doc-id>
        <is-also>
            <doc-id>RFC4611</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0122</doc-id>
        <is-also>
            <doc-id>RFC4632</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0123</doc-id>
        <is-also>
            <doc-id>RFC4697</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0124</doc-id>
        <is-also>
            <doc-id>RFC4774</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0125</doc-id>
        <is-also>
            <doc-id>RFC4775</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0126</doc-id>
        <is-also>
            <doc-id>RFC4786</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0127</doc-id>
        <is-also>
            <doc-id>RFC4787</doc-id>
            <doc-id>RFC6888</doc-id>
            <doc-id>RFC7857</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0128</doc-id>
        <is-also>
            <doc-id>RFC4928</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0129</doc-id>
        <is-also>
            <doc-id>RFC4929</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0130</doc-id>
        <is-also>
            <doc-id>RFC4940</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0131</doc-id>
        <is-also>
            <doc-id>RFC4961</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0132</doc-id>
        <is-also>
            <doc-id>RFC4962</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0133</doc-id>
        <is-also>
            <doc-id>RFC9743</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0134</doc-id>
        <is-also>
            <doc-id>RFC5068</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0135</doc-id>
        <is-also>
            <doc-id>RFC5135</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0136</doc-id>
        <is-also>
            <doc-id>RFC5266</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0137</doc-id>
        <is-also>
            <doc-id>RFC5137</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0138</doc-id>
        <is-also>
            <doc-id>RFC5248</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0139</doc-id>
        <is-also>
            <doc-id>RFC5249</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0140</doc-id>
        <is-also>
            <doc-id>RFC5358</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0141</doc-id>
        <is-also>
            <doc-id>RFC9542</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0142</doc-id>
        <is-also>
            <doc-id>RFC5382</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0143</doc-id>
        <is-also>
            <doc-id>RFC5383</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0144</doc-id>
        <is-also>
            <doc-id>RFC5359</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0145</doc-id>
        <is-also>
            <doc-id>RFC8085</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0146</doc-id>
        <is-also>
            <doc-id>RFC5406</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0147</doc-id>
        <is-also>
            <doc-id>RFC5407</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0148</doc-id>
        <is-also>
            <doc-id>RFC5508</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0149</doc-id>
        <is-also>
            <doc-id>RFC5589</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0150</doc-id>
        <is-also>
            <doc-id>RFC5597</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0151</doc-id>
        <is-also>
            <doc-id>RFC5615</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0152</doc-id>
        <is-also>
            <doc-id>RFC5625</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0153</doc-id>
        <is-also>
            <doc-id>RFC6598</doc-id>
            <doc-id>RFC6890</doc-id>
            <doc-id>RFC8190</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0154</doc-id>
        <is-also>
            <doc-id>RFC5774</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0155</doc-id>
        <is-also>
            <doc-id>RFC5855</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0156</doc-id>
        <is-also>
            <doc-id>RFC6056</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0157</doc-id>
        <is-also>
            <doc-id>RFC6177</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0158</doc-id>
        <is-also>
            <doc-id>RFC6158</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0159</doc-id>
        <is-also>
            <doc-id>RFC6191</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0160</doc-id>
        <is-also>
            <doc-id>RFC6280</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0161</doc-id>
        <is-also>
            <doc-id>RFC6291</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0162</doc-id>
        <is-also>
            <doc-id>RFC6302</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0163</doc-id>
        <is-also>
            <doc-id>RFC6303</doc-id>
            <doc-id>RFC7793</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0164</doc-id>
        <is-also>
            <doc-id>RFC6328</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0165</doc-id>
        <is-also>
            <doc-id>RFC6335</doc-id>
            <doc-id>RFC7605</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0166</doc-id>
        <is-also>
            <doc-id>RFC6365</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0167</doc-id>
        <is-also>
            <doc-id>RFC6377</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0168</doc-id>
        <is-also>
            <doc-id>RFC6398</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0169</doc-id>
        <is-also>
            <doc-id>RFC6382</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0170</doc-id>
        <is-also>
            <doc-id>RFC6390</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0171</doc-id>
        <is-also>
            <doc-id>RFC6441</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0172</doc-id>
        <is-also>
            <doc-id>RFC6472</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0173</doc-id>
        <is-also>
            <doc-id>RFC6484</doc-id>
            <doc-id>RFC7382</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0174</doc-id>
        <is-also>
            <doc-id>RFC6489</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0175</doc-id>
        <is-also>
            <doc-id>RFC6557</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0176</doc-id>
        <is-also>
            <doc-id>RFC6576</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0177</doc-id>
        <is-also>
            <doc-id>RFC6540</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0178</doc-id>
        <is-also>
            <doc-id>RFC6648</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0179</doc-id>
        <is-also>
            <doc-id>RFC6649</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0180</doc-id>
        <is-also>
            <doc-id>RFC6853</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0181</doc-id>
        <is-also>
            <doc-id>RFC6881</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0182</doc-id>
        <is-also>
            <doc-id>RFC6916</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0183</doc-id>
        <is-also>
            <doc-id>RFC6963</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0184</doc-id>
        <is-also>
            <doc-id>RFC7013</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0185</doc-id>
        <is-also>
            <doc-id>RFC7115</doc-id>
            <doc-id>RFC9319</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0186</doc-id>
        <is-also>
            <doc-id>RFC7126</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0187</doc-id>
        <is-also>
            <doc-id>RFC7227</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0188</doc-id>
        <is-also>
            <doc-id>RFC7258</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0189</doc-id>
        <is-also>
            <doc-id>RFC7279</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0190</doc-id>
        <is-also>
            <doc-id>RFC8820</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0191</doc-id>
        <is-also>
            <doc-id>RFC7319</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0193</doc-id>
        <is-also>
            <doc-id>RFC7423</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0194</doc-id>
        <is-also>
            <doc-id>RFC7454</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0195</doc-id>
        <is-also>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9325</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0196</doc-id>
        <is-also>
            <doc-id>RFC7526</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0197</doc-id>
        <is-also>
            <doc-id>RFC7567</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0198</doc-id>
        <is-also>
            <doc-id>RFC7608</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0199</doc-id>
        <is-also>
            <doc-id>RFC7610</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0200</doc-id>
        <is-also>
            <doc-id>RFC1984</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0201</doc-id>
        <is-also>
            <doc-id>RFC7696</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0202</doc-id>
        <is-also>
            <doc-id>RFC7772</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0203</doc-id>
        <is-also>
            <doc-id>RFC7803</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0204</doc-id>
        <is-also>
            <doc-id>RFC7934</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0205</doc-id>
        <is-also>
            <doc-id>RFC7942</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0206</doc-id>
        <is-also>
            <doc-id>RFC7926</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0207</doc-id>
        <is-also>
            <doc-id>RFC8027</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0208</doc-id>
        <is-also>
            <doc-id>RFC8084</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0209</doc-id>
        <is-also>
            <doc-id>RFC9609</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0210</doc-id>
        <is-also>
            <doc-id>RFC8180</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0211</doc-id>
        <is-also>
            <doc-id>RFC8207</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0212</doc-id>
        <is-also>
            <doc-id>RFC8252</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0213</doc-id>
        <is-also>
            <doc-id>RFC8313</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0214</doc-id>
        <is-also>
            <doc-id>RFC8327</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0215</doc-id>
        <is-also>
            <doc-id>RFC8340</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0216</doc-id>
        <is-also>
            <doc-id>RFC8407</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0217</doc-id>
        <is-also>
            <doc-id>RFC8421</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0218</doc-id>
        <is-also>
            <doc-id>RFC8429</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0219</doc-id>
        <is-also>
            <doc-id>RFC9499</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0220</doc-id>
        <is-also>
            <doc-id>RFC8504</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0221</doc-id>
        <is-also>
            <doc-id>RFC8521</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0222</doc-id>
        <is-also>
            <doc-id>RFC8552</doc-id>
            <doc-id>RFC8553</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0223</doc-id>
        <is-also>
            <doc-id>RFC8633</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0224</doc-id>
        <is-also>
            <doc-id>RFC8634</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0225</doc-id>
        <is-also>
            <doc-id>RFC8725</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0226</doc-id>
        <is-also>
            <doc-id>RFC8718</doc-id>
            <doc-id>RFC8719</doc-id>
            <doc-id>RFC9137</doc-id>
            <doc-id>RFC9712</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0227</doc-id>
        <is-also>
            <doc-id>RFC8758</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0228</doc-id>
        <is-also>
            <doc-id>RFC8862</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0229</doc-id>
        <is-also>
            <doc-id>RFC8815</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0230</doc-id>
        <is-also>
            <doc-id>RFC8900</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0231</doc-id>
        <is-also>
            <doc-id>RFC8906</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0232</doc-id>
        <is-also>
            <doc-id>RFC8932</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0233</doc-id>
        <is-also>
            <doc-id>RFC8961</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0234</doc-id>
        <is-also>
            <doc-id>RFC9096</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0235</doc-id>
        <is-also>
            <doc-id>RFC9210</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0236</doc-id>
        <is-also>
            <doc-id>RFC9276</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0237</doc-id>
        <is-also>
            <doc-id>RFC9364</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0238</doc-id>
        <is-also>
            <doc-id>RFC9455</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0239</doc-id>
        <is-also>
            <doc-id>RFC9501</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0240</doc-id>
        <is-also>
            <doc-id>RFC9700</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0241</doc-id>
        <is-also>
            <doc-id>RFC9726</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0243</doc-id>
        <is-also>
            <doc-id>RFC9813</doc-id>
        </is-also>
    </bcp-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>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>RFC4949</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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0001</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0002</doc-id>
        <title>Host software</title>
        <author>
            <name>B. Duvall</name>
        </author>
        <date>
            <month>April</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2</errata-url>
        <doi>10.17487/RFC0002</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0003</doc-id>
        <title>Documentation conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoleted-by>
            <doc-id>RFC0010</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3</errata-url>
        <doi>10.17487/RFC0003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0004</doc-id>
        <title>Network timetable</title>
        <author>
            <name>E.B. Shapiro</name>
        </author>
        <date>
            <month>March</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0004</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5</errata-url>
        <doi>10.17487/RFC0005</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0006</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0007</doc-id>
        <title>Host-IMP interface</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>May</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0007</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0008</doc-id>
        <title>ARPA Network Functional Specifications</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>May</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>0</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0008</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0009</doc-id>
        <title>Host Software</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>May</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>15</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0009</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0010</doc-id>
        <title>Documentation conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0010</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <obsoleted-by>
            <doc-id>RFC0033</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0011</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0012</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0013</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0015</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0016</doc-id>
        <title>M.I.T</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>August</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0016</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0017</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0018</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0019</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <is-also>
            <doc-id>STD0080</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc20</errata-url>
        <doi>10.17487/RFC0020</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0021</doc-id>
        <title>Network meeting</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0021</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0022</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0024</doc-id>
        <title>Documentation Conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>November</month>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0024</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0025</doi>
    </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>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0027</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0028</doc-id>
        <title>Time Standards</title>
        <author>
            <name>W.K. English</name>
        </author>
        <date>
            <month>January</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0028</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <see-also>
            <doc-id>RFC0028</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0029</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0030</doc-id>
        <title>Documentation Conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0030</doi>
    </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>
            <year>1968</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc31</errata-url>
        <doi>10.17487/RFC0031</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0032</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc33</errata-url>
        <doi>10.17487/RFC0033</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0035</doc-id>
        <title>Network Meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0035</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0036</doc-id>
        <title>Protocol Notes</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0036</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0037</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0038</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0036</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0039</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0040</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0041</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0042</doc-id>
        <title>Message Data Types</title>
        <author>
            <name>E. Ancona</name>
        </author>
        <date>
            <month>March</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0043</doc-id>
        <title>Proposed Meeting</title>
        <author>
            <name>A.G. Nemeth</name>
        </author>
        <date>
            <month>April</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0043</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0036</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0044</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0045</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0046</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updates>
            <doc-id>RFC0033</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0047</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0048</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0049</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0050</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>0</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0051</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updated-by>
            <doc-id>RFC0069</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0052</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0053</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <updated-by>
            <doc-id>RFC0057</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0054</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0055</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0056</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0054</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc57</errata-url>
        <doi>10.17487/RFC0057</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0058</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc59</errata-url>
        <doi>10.17487/RFC0059</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0060</doc-id>
        <title>A Simplified NCP Protocol</title>
        <author>
            <name>R. Kalin</name>
        </author>
        <date>
            <month>July</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0060</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <obsoleted-by>
            <doc-id>RFC0062</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0061</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <obsoletes>
            <doc-id>RFC0061</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0062</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0063</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0064</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0065</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc66</errata-url>
        <doi>10.17487/RFC0066</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0067</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0068</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0052</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0069</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <updated-by>
            <doc-id>RFC0228</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0070</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0071</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0072</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0073</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <updated-by>
            <doc-id>RFC0217</doc-id>
            <doc-id>RFC0225</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0075</doc-id>
        <title>Network Meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0075</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0077</doc-id>
        <title>Network meeting report</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0077</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0079</doc-id>
        <title>Logger Protocol error</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>November</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0079</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0080</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0082</doc-id>
        <title>Network Meeting Notes</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>December</month>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0082</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0083</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0084</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0085</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <updated-by>
            <doc-id>RFC0125</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc86</errata-url>
        <doi>10.17487/RFC0086</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0087</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <obsoleted-by>
            <doc-id>RFC0189</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc88</errata-url>
        <doi>10.17487/RFC0088</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc89</errata-url>
        <doi>10.17487/RFC0089</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc90</errata-url>
        <doi>10.17487/RFC0090</doi>
    </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>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0091</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0066</doc-id>
            <doc-id>RFC0080</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0093</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0095</doc-id>
        <title>Distribution of NWG/RFC's through the NIC</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <obsoleted-by>
            <doc-id>RFC0155</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0095</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0096</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0097</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <updated-by>
            <doc-id>RFC0123</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0098</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0099</doc-id>
        <title>Network Meeting</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <date>
            <month>February</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0116</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0099</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0100</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <updated-by>
            <doc-id>RFC0108</doc-id>
            <doc-id>RFC0123</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0101</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0107</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0102</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0103</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0104</doc-id>
        <title>Link 191</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>C. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0104</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <updated-by>
            <doc-id>RFC0217</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0105</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0106</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0107</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>RFC0101</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0108</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0109</doc-id>
        <title>Level III Server Protocol for the Lincoln Laboratory 360/67 Host</title>
        <author>
            <name>J. Winett</name>
        </author>
        <date>
            <month>March</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <see-also>
            <doc-id>RFC0393</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0109</doi>
    </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. Winett</name>
        </author>
        <date>
            <month>March</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0135</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0110</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0112</doc-id>
        <title>User/Server Site Protocol: Network Host Questionnaire</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>April</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0112</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updated-by>
            <doc-id>RFC0227</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0113</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0114</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0115</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0116</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0117</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0119</doc-id>
        <title>Network Fortran Subprograms</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>April</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0120</doc-id>
        <title>Network PL1 subprograms</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>April</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0120</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0121</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0122</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0123</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc124</errata-url>
        <doi>10.17487/RFC0124</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0125</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0126</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc127</errata-url>
        <doi>10.17487/RFC0127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0128</doc-id>
        <title>Bytes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0128</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <updated-by>
            <doc-id>RFC0147</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0129</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0111</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0130</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0116</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0131</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0132</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0114</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0134</doc-id>
        <title>Network Graphics meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>April</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0134</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0110</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0135</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0136</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <updated-by>
            <doc-id>RFC0139</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0137</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0138</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0139</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0149</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0140</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0114</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0141</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0142</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0143</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0144</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0145</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0146</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0129</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0147</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0123</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0148</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0140</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0149</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0150</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>RFC0127</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0151</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0152</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0154</doc-id>
        <title>Exposition Style</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoletes>
            <doc-id>RFC0132</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0154</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0155</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0116</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0156</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0157</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0158</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0160</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0162</doc-id>
        <title>NETBUGGER3</title>
        <author>
            <name>M. Kampe</name>
        </author>
        <date>
            <month>May</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc162</errata-url>
        <doi>10.17487/RFC0162</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>DTP</kw>
            <kw>data</kw>
            <kw>manager</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0163</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0164</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0165</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0166</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <see-also>
            <doc-id>RFC0129</doc-id>
            <doc-id>RFC0147</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0167</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0169</doc-id>
        <title>COMPUTER NETWORKS</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0169</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <obsoleted-by>
            <doc-id>RFC0200</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0170</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0171</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0172</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0173</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0174</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0175</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0176</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0177</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0178</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0179</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0180</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0177</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0181</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0182</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0183</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0184</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0185</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0186</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0187</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0188</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0189</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0190</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0191</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0192</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0193</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc194</errata-url>
        <doi>10.17487/RFC0194</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0195</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <obsoleted-by>
            <doc-id>RFC0221</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0196</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0197</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0198</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0199</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0200</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0202</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0204</doc-id>
        <title>Sockets in use</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0234</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0204</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0206</doc-id>
        <title>A User TELNET Description of an Initial Implementation</title>
        <author>
            <name>J. White</name>
        </author>
        <date>
            <month>August</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0206</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoleted-by>
            <doc-id>RFC0212</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0208</doc-id>
        <title>Address tables</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0208</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0209</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0210</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0211</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0212</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0214</doc-id>
        <title>Network checkpoint</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <date>
            <month>August</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoletes>
            <doc-id>RFC0198</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0214</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0215</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0216</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0217</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0218</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0219</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0221</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0222</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0223</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0224</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0074</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0225</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoleted-by>
            <doc-id>RFC0247</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0226</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>RFC0113</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0228</doc-id>
        <title>Clarification</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>September</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0070</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0229</doc-id>
        <title>Standard host names</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoleted-by>
            <doc-id>RFC0236</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0229</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0230</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0231</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0232</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0233</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0222</doc-id>
            <doc-id>RFC0204</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0235</doc-id>
        <title>Site status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>September</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <obsoleted-by>
            <doc-id>RFC0240</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0236</doc-id>
        <title>Standard host names</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoletes>
            <doc-id>RFC0229</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0236</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoleted-by>
            <doc-id>RFC0273</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0237</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0238</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0240</doc-id>
        <title>Site Status</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>September</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0240</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0241</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0242</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <obsoleted-by>
            <doc-id>RFC0290</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0243</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0246</doc-id>
        <title>Network Graphics meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>October</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0246</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <obsoletes>
            <doc-id>RFC0226</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0247</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0249</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0251</doc-id>
        <title>Weather data</title>
        <author>
            <name>D. Stern</name>
        </author>
        <date>
            <month>October</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0252</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>October</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0252</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0253</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>0</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0254</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0256</doc-id>
        <title>IMPSYS change notification</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <date>
            <month>November</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0256</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0263</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0264</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0266</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>November</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0267</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>November</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0268</doc-id>
        <title>Graphics facilities information</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0268</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0122</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0269</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>NIC7959</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc270</errata-url>
        <doi>10.17487/RFC0270</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0271</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoletes>
            <doc-id>RFC0237</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0273</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0274</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0276</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <obsoletes>
            <doc-id>RFC0221</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0278</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0280</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0265</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0281</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0282</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <updates>
            <doc-id>RFC0189</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0283</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0285</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0286</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0288</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>January</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0288</doi>
    </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>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoleted-by>
            <doc-id>RFC0384</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0289</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <obsoletes>
            <doc-id>RFC0243</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0290</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0291</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <obsoleted-by>
            <doc-id>RFC0493</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0293</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>January</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0293</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0265</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0294</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0295</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0296</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0298</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>February</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0298</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0299</doc-id>
        <title>Information Management System</title>
        <author>
            <name>D. Hopkin</name>
        </author>
        <date>
            <month>February</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0299</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0300</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0301</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0302</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0303</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc304</errata-url>
        <doi>10.17487/RFC0304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0305</doc-id>
        <title>Unknown Host Numbers</title>
        <author>
            <name>R. Alter</name>
        </author>
        <date>
            <month>February</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0306</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>February</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0306</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0307</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0530</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0308</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>DTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0309</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0310</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0311</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0312</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0313</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0314</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0315</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>March</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0315</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0316</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoleted-by>
            <doc-id>RFC0604</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0318</doc-id>
        <title>Telnet Protocols</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0318</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0319</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>March</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0319</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0320</doc-id>
        <title>Workshop on Hard Copy Line Graphics</title>
        <author>
            <name>R. Reddy</name>
        </author>
        <date>
            <month>March</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0320</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0321</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0322</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <updated-by>
            <doc-id>RFC0388</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0324</doc-id>
        <title>RJE Protocol meeting</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0324</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0326</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>April</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0326</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0327</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0328</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0330</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>April</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0330</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoleted-by>
            <doc-id>RFC0343</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0332</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>April</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0332</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0333</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0334</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0335</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0336</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0338</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0339</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <see-also>
            <doc-id>RFC0328</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0340</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0342</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0344</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>May</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0344</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>MIP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0346</doc-id>
        <title>Satellite Considerations</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0347</doc-id>
        <title>Echo process</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0348</doc-id>
        <title>Discard Process</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0348</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoleted-by>
            <doc-id>RFC0433</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC0204</doc-id>
            <doc-id>RFC0322</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0349</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0350</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0351</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0353</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>June</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0353</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0354</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0355</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0356</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0357</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <obsoletes>
            <doc-id>RFC0343</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0359</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <obsoleted-by>
            <doc-id>RFC0407</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0360</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0362</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>June</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0362</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0363</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0364</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0366</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>July</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0367</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>July</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0367</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0368</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0370</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>July</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0370</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0371</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0373</doc-id>
        <title>Arbitrary Character Sets</title>
        <author>
            <name>J. McCarthy</name>
        </author>
        <date>
            <month>July</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0373</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0374</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0370</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0376</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0377</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoleted-by>
            <doc-id>RFC0391</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0378</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0379</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0394</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0381</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0382</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <obsoletes>
            <doc-id>RFC0289</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0384</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0385</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0386</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updated-by>
            <doc-id>RFC0401</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0388</doc-id>
        <title>NCP statistics</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>August</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0323</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0388</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoleted-by>
            <doc-id>RFC0423</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0390</doc-id>
        <title>TSO Scenario</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>September</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0390</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoletes>
            <doc-id>RFC0378</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0391</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0392</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0393</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0381</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0394</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0395</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0474</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0396</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0397</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0398</doc-id>
        <title>UCSB Online Graphics</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <author>
            <name>E. Faeh</name>
        </author>
        <date>
            <month>September</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0398</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0399</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0400</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>RFC0387</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0401</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <obsoletes>
            <doc-id>RFC0363</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0402</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0403</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0405</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0404</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0404</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0405</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0406</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RJE</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0360</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0407</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0408</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0409</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0410</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0412</doc-id>
        <title>User FTP Documentation</title>
        <author>
            <name>G. Hicks</name>
        </author>
        <date>
            <month>November</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0412</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0413</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0385</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0415</doc-id>
        <title>Tenex bandwidth</title>
        <author>
            <name>H. Murray</name>
        </author>
        <date>
            <month>November</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0415</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0416</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0418</doc-id>
        <title>Server File Transfer Under TSS/360 At NASA-Ames Research Center</title>
        <author>
            <name>W. Hathaway</name>
        </author>
        <date>
            <month>November</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0418</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0419</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0420</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0421</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0422</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoletes>
            <doc-id>RFC0389</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0423</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0426</doc-id>
        <title>Reconnection Protocol</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>January</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0426</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0429</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0430</doi>
    </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>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoletes>
            <doc-id>RFC0399</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0122</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0432</doc-id>
        <title>Network logical map</title>
        <author>
            <name>N. Neigus</name>
        </author>
        <date>
            <month>December</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0433</doc-id>
        <title>Socket number list</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0433</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoleted-by>
            <doc-id>RFC0447</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0434</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <updates>
            <doc-id>RFC0318</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0435</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0436</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0437</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0438</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0439</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0440</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0441</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <updated-by>
            <doc-id>RFC0449</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0442</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0443</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0445</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0446</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0447</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0448</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0442</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0449</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0450</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0452</doc-id>
        <title>TELNET Command at Host LL</title>
        <author>
            <name>J. Winett</name>
        </author>
        <date>
            <month>February</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0452</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0453</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0354</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0454</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0455</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0457</doc-id>
        <title>TIPUG</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>February</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0457</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0459</doc-id>
        <title>Network questionnaires</title>
        <author>
            <name>W. Kantrowitz</name>
        </author>
        <date>
            <month>February</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0460</doc-id>
        <title>NCP survey</title>
        <author>
            <name>C. Kline</name>
        </author>
        <date>
            <month>February</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0460</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0461</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0462</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0463</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0464</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0466</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <updated-by>
            <doc-id>RFC0492</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0467</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0468</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>network</kw>
            <kw>mail</kw>
            <kw>meeting</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0469</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0470</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0471</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0472</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0473</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>RFC0396</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0474</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0475</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoletes>
            <doc-id>RFC0447</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0476</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0477</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0478</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0479</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0480</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0497</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0482</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0483</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0485</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>RJE</kw>
            <kw>FTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0486</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0487</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0488</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0489</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0490</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0491</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <updates>
            <doc-id>RFC0467</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0492</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <obsoletes>
            <doc-id>RFC0292</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0493</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0494</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoletes>
            <doc-id>RFC0158</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0562</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0495</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0496</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updates>
            <doc-id>RFC0482</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0509</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0497</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0498</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0499</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0500</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0501</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0503</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0504</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>free</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0505</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0506</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0508</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updates>
            <doc-id>RFC0497</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0522</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0509</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0510</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0511</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0512</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0514</doc-id>
        <title>Network make-work</title>
        <author>
            <name>W. Kantrowitz</name>
        </author>
        <date>
            <month>June</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0514</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0516</doc-id>
        <title>Lost message detection</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0516</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0519</doc-id>
        <title>Resource Evaluation</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>June</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0519</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0520</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0521</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updates>
            <doc-id>RFC0509</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0522</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updated-by>
            <doc-id>RFC0530</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0523</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0524</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0525</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0527</doc-id>
        <title>ARPAWOCKY</title>
        <author>
            <name>R. Merryman</name>
        </author>
        <date>
            <month>May</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0527</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0528</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0529</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>0</page-count>
        <updates>
            <doc-id>RFC0308</doc-id>
            <doc-id>RFC0523</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0530</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0531</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>server</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0532</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0533</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0534</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0535</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0537</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0556</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0538</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0539</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc542</errata-url>
        <doi>10.17487/RFC0542</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0543</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0544</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0545</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0546</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0547</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0548</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0549</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0551</doc-id>
        <title>NYU, ANL, and LBL Joining the Net</title>
        <author>
            <name>Y. Feinroth</name>
        </author>
        <author>
            <name>R. Fink</name>
        </author>
        <date>
            <month>August</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0551</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0552</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0553</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0555</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updates>
            <doc-id>RFC0538</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0556</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0557</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0559</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <updated-by>
            <doc-id>RFC0581</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0560</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updated-by>
            <doc-id>RFC0680</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0561</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>RFC0495</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0562</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0563</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0565</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <updated-by>
            <doc-id>RFC0579</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0566</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0568</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0567</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0567</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0568</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>NETED</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0569</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0571</doc-id>
        <title>TENEX FTP PROBLEM</title>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>November</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0571</doi>
    </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. Bhushan</name>
        </author>
        <date>
            <month>September</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0573</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0574</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0577</doc-id>
        <title>Mail priority</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0577</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0578</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0566</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0586</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0579</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0582</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0580</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0560</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0581</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0580</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0582</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0584</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0585</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <updates>
            <doc-id>RFC0579</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc586</errata-url>
        <doi>10.17487/RFC0586</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0588</doc-id>
        <title>London Node Is Now Up</title>
        <author>
            <name>A. Stokes</name>
        </author>
        <date>
            <month>October</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0588</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0589</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0590</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0591</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0592</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0593</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0594</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0595</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0596</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <updated-by>
            <doc-id>RFC0603</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0597</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>PDF</file-format>
        </format>
        <page-count>0</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0598</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0599</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>Discusses some unusual interface issues for the Plato terminal.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0600</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0601</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>security</kw>
            <kw>violations</kw>
            <kw>TIP</kw>
            <kw>arpanet</kw>
        </keywords>
        <abstract><p>Susceptibility of ARPANET to security violations.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0602</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>Questions about the ARPANET topology described in RFC 597.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0604</doc-id>
        <title>Assigned link numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>Modifies official host-host protocol.  Replaces RFC 377.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0604</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>lists</kw>
            <kw>names</kw>
            <kw>host</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0606</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>solutions</kw>
            <kw>weakness</kw>
            <kw>ftp</kw>
        </keywords>
        <abstract><p>An old version; see RFC 624; see also RFCs 614, 542 and 640.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0607</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>Response to RFC 606; see also RFCs 627, 625 and 623.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0810</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0608</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>See also RFCs 621 and 620.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0609</doi>
    </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>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <abstract><p>Preliminary results of the language design; a model for data languagea semantics; future considerations.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0610</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>Expansion of Host-Going-Down and addition of Dead-Host-Status Message.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0611</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0612</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updates>
            <doc-id>RFC0603</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0613</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>ftp</kw>
            <kw>weakness</kw>
            <kw>solutions</kw>
        </keywords>
        <abstract><p>See also RFCs 624, 542 and 640.</p></abstract>
        <updates>
            <doc-id>RFC0542</doc-id>
            <doc-id>RFC0607</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0614</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <obsoleted-by>
            <doc-id>RFC0645</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0616</doc-id>
        <title>LATEST NETWORK MAPS</title>
        <author>
            <name>D. Walden</name>
        </author>
        <date>
            <month>February</month>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>maps</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0616</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>telnet</kw>
        </keywords>
        <abstract><p>Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0617</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>Distribution of NCP and IMP message types by actual measurement.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0618</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>Actual measurements of round-trip times.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0619</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>tenex</kw>
        </keywords>
        <abstract><p>In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0620</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>See also RFCs 620 and 609.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0621</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>Modification of previous policy.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0622</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>See also RFCs 627, 625, 608 and 606.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0623</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>ftp</kw>
            <kw>telnet</kw>
        </keywords>
        <abstract><p>Design changes and slight modifications.  Replaces RFC 607; see also RFCs 614, 542 and 640.</p></abstract>
        <obsoletes>
            <doc-id>RFC0607</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0624</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>See also RFCs 606, 608, 623 and 627.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0625</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0626</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>See also RFCs 606, 608, 623 and 625.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0627</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0628</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0629</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>Describes FTP reply-code usage in TENEX mail processing.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0630</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0631</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0632</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>An old version; see RFC 638.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0638</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0633</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0634</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>Theoretical and practical motivation for redesign</kw>
            <kw>multipacket messages</kw>
            <kw>host retransmission</kw>
            <kw>duplicate detection</kw>
            <kw>sequencing</kw>
            <kw>acknowledgement</kw>
        </keywords>
        <abstract><p>This paper presents some theoretical and practical motivations for the redesign of the ARPANET communication protocols.  Issues concerning multipacket messages, Host retransmission, duplicate detection, sequencing, and acknowledgment are discussed.  Simplifications to the IMP/IMP protocol are proposed on the assumption that new Host level protocols are adopted.  Familiarity with the current protocol designs is probably necessary since many of the arguments refer to details in the present protocol design.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0635</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>Obtaining/maintaining connections; recovery from lost connections; connection-state changes.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0636</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0637</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>Corrects RFC 633.</p></abstract>
        <obsoletes>
            <doc-id>RFC0633</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0638</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Updates RFC 542.</p></abstract>
        <updates>
            <doc-id>RFC0542</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc640</errata-url>
        <doi>10.17487/RFC0640</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0643</doc-id>
        <title>Network Debugging Protocol</title>
        <author>
            <name>E. Mader</name>
        </author>
        <date>
            <month>July</month>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0643</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0644</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.</p></abstract>
        <obsoletes>
            <doc-id>RFC0615</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0645</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>Approaches to Front-End protocol processing using available hardware and software.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0647</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoleted-by>
            <doc-id>RFC0859</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0651</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-OCRD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0652</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>TOPT-OHT</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0653</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>TOPT-OHTD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0654</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>TOPT-OFD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0655</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>TOPT-OVT</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0656</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>TOPT-OVTD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0657</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>TOPT-OLD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0658</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>Options defined in RFCs 651-658.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0659</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0661</doc-id>
        <title>Protocol information</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>An old version; see RFC 694.</p></abstract>
        <updated-by>
            <doc-id>RFC0694</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0661</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>Experimenting with host output buffers to improve throughput.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0662</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>ARPANET</kw>
            <kw>Host</kw>
        </keywords>
        <abstract><p>Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0663</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>Discusses and proposes a common command language.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0667</doc-id>
        <title>Host Ports</title>
        <author>
            <name>S.G. Chipman</name>
        </author>
        <date>
            <month>December</month>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>Approved scheme to connect host ports to the network.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0667</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>An earlier poll of Telnet server implementation status.  Updates RFC 702; see also RFCs 703 and 679.</p></abstract>
        <updates>
            <doc-id>RFC0702</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0679</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0669</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Experience with implementation in RSEXEC context.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0671</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Applicability of TIP/TENEX protocols beyond TIP accounting.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0672</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0674</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <abstract><p>The first detailed specification of TCP; see RFC 793.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc675</errata-url>
        <doi>10.17487/RFC0675</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0678</doc-id>
        <title>Standard file formats</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>For transmission of documents across different environments.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0678</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>An earlier poll of Telnet server implementation status.  Updates RFCs 701, 702 and 669; see also RFC 703.</p></abstract>
        <updates>
            <doc-id>RFC0669</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0703</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0679</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.</p></abstract>
        <updates>
            <doc-id>RFC0561</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0681</doc-id>
        <title>Network UNIX</title>
        <author>
            <name>S. Holmgren</name>
        </author>
        <date>
            <month>March</month>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0681</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>paged</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>Tenex</kw>
        </keywords>
        <abstract><p>Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.</p></abstract>
        <updates>
            <doc-id>RFC0354</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0683</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Issues in designing distributed computing systems.  Shortcomings of RFC 674; see also RFCs 542 and 354.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0684</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>The contribution of ARPANET communication to response time.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0685</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0686</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0687</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0688</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>Describes the internal states of an NCP connection in the TENEX implementation.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0689</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>Comments on suggestions in RFC 687; see also RFCs 692 and 696.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0690</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0691</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.</p></abstract>
        <updates>
            <doc-id>RFC0690</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0692</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.</p></abstract>
        <updates>
            <doc-id>RFC0661</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0694</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0695</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0696</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>Discusses FTP login access to "files only" directories.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0697</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TOPT-EXT</kw>
        </keywords>
        <abstract><p>Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5198</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0698</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0699</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0700</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <updated-by>
            <doc-id>RFC0702</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0701</doi>
    </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>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0701</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0669</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0702</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <updates>
            <doc-id>RFC0679</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0703</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoletes>
            <doc-id>RFC0687</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0704</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0705</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0706</doi>
    </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>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0707</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0708</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0712</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0713</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0714</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0717</doc-id>
        <title>Assigned Network Numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0717</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0719</doc-id>
        <title>Discussion on RCTE</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0719</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0720</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0721</doi>
    </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>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0722</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <obsoleted-by>
            <doc-id>RFC0733</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0724</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0725</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>TOPT-REM</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0726</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TOPT-LOGO</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0727</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0728</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoleted-by>
            <doc-id>RFC0735</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0730</doc-id>
        <title>Extensible field addressing</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0730</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <obsoleted-by>
            <doc-id>RFC0732</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0731</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0732</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0734</doc-id>
        <title>SUPDUP Protocol</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>October</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SUPDUP</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0734</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0735</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>TOPT-SUP</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0737</doc-id>
        <title>FTP extension: XSEN</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>October</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0738</doc-id>
        <title>Time server</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>October</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0739</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0740</doc-id>
        <title>NETRJS Protocol</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>November</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>NETRJS</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0599</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0740</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0742</doc-id>
        <title>NAME/FINGER Protocol</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>December</month>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0742</doi>
    </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>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0743</doi>
    </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>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0745</doc-id>
        <title>JANUS interface specifications</title>
        <author>
            <name>M. Beeler</name>
        </author>
        <date>
            <month>March</month>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>JANUS</kw>
            <kw>interface</kw>
            <kw>specifications</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0746</doc-id>
        <title>SUPDUP graphics extension</title>
        <author>
            <name>R. Stallman</name>
        </author>
        <date>
            <month>March</month>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0746</doi>
    </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>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0747</doi>
    </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>1</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC0748</doi>
    </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>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-SUPO</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0750</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0750</doi>
    </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>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0751</doi>
    </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>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0753</doc-id>
        <title>Internet Message Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0753</doi>
    </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>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0755</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0755</doi>
    </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>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0756</doi>
    </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>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0758</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0759</doc-id>
        <title>Internet Message Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>MPM</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0759</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0760</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>TCP</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC0793</doc-id>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc761</errata-url>
        <doi>10.17487/RFC0761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0762</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0763</doc-id>
        <title>Role mailboxes</title>
        <author>
            <name>M.D. Abrams</name>
        </author>
        <date>
            <month>May</month>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0764</doc-id>
        <title>Telnet Protocol specification</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <obsoleted-by>
            <doc-id>RFC0854</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0764</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0765</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <obsoleted-by>
            <doc-id>RFC0774</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0766</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0768</doc-id>
        <title>User Datagram Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>UDP</kw>
        </keywords>
        <is-also>
            <doc-id>STD0006</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0768</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0770</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0770</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0771</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0772</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0773</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <obsoletes>
            <doc-id>RFC0766</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0774</doi>
    </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>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0776</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0776</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0777</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>CLOCK</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0778</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>TOPT-SNDL</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0779</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0780</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0781</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0782</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc783</errata-url>
        <doi>10.17487/RFC0783</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>MTP</kw>
            <kw>email</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0784</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>MTP</kw>
            <kw>email</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0785</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>MTP</kw>
            <kw>NIMAIL</kw>
            <kw>TOPS20</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0786</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc787</errata-url>
        <doi>10.17487/RFC0787</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0788</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0790</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0791</doc-id>
        <title>Internet Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>IPv4</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0760</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1349</doc-id>
            <doc-id>RFC2474</doc-id>
            <doc-id>RFC6864</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc791</errata-url>
        <doi>10.17487/RFC0791</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>ICMP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0777</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0950</doc-id>
            <doc-id>RFC4884</doc-id>
            <doc-id>RFC6633</doc-id>
            <doc-id>RFC6918</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc792</errata-url>
        <doi>10.17487/RFC0792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0793</doc-id>
        <title>Transmission Control Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>TCP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0761</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1122</doc-id>
            <doc-id>RFC3168</doc-id>
            <doc-id>RFC6093</doc-id>
            <doc-id>RFC6528</doc-id>
        </updated-by>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc793</errata-url>
        <doi>10.17487/RFC0793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0794</doc-id>
        <title>Pre-emption</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>September</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <updates>
            <doc-id>IEN125</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0795</doc-id>
        <title>Service mappings</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0796</doc-id>
        <title>Address mappings</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <obsoletes>
            <doc-id>IEN115</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0796</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0797</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0798</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0799</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0800</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0801</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0851</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0802</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0803</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This is the CCITT standard for group 3 facsimile encoding.  This is useful for data compression of bit map data.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc804</errata-url>
        <doi>10.17487/RFC0804</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0805</doi>
    </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>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>107</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0841</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0806</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0807</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0808</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0809</doc-id>
        <title>UCL facsimile system</title>
        <author>
            <name>T. Chang</name>
        </author>
        <date>
            <month>February</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0809</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0810</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0953</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0811</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0812</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0813</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0814</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0815</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0816</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0817</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>RTELNET</kw>
        </keywords>
        <abstract><p>This RFC is the specification of an application protocol.  Any host that implements this application level service must follow this protocol.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0819</doc-id>
        <title>The Domain Naming Convention for Internet User Applications</title>
        <author>
            <name>Z. Su</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc819</errata-url>
        <doi>10.17487/RFC0819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0820</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This RFC is an old version, see RFC 870.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0820</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>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.</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0821</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>MAIL</kw>
        </keywords>
        <abstract><p>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.</p></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>RFC2156</doc-id>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC1148</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0011</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc822</errata-url>
        <doi>10.17487/RFC0822</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>GGP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>IEN109</doc-id>
            <doc-id>IEN30</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc823</errata-url>
        <doi>10.17487/RFC0823</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0824</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0826</doc-id>
        <title>An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware</title>
        <author>
            <name>D. Plummer</name>
        </author>
        <date>
            <month>November</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ARP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC5227</doc-id>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0037</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc826</errata-url>
        <doi>10.17487/RFC0826</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC0904</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0827</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0828</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0829</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0830</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0831</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0832</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0833</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0832</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0833</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0833</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0834</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0834</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0835</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0835</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0836</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0836</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0837</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0837</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0838</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0838</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0839</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0839</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0840</doc-id>
        <title>Official protocols</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This RFC has been revised, see RFC 880.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0880</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0840</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>117</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0806</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0841</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0842</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0843</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0843</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0844</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0845</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0846</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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).</p></abstract>
        <obsoletes>
            <doc-id>RFC0846</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0847</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0848</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0849</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1036</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0850</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0851</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0852</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>TELNET</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0764</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5198</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0008</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc854</errata-url>
        <doi>10.17487/RFC0854</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TELNET</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>NIC18640</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0008</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0855</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0856</doc-id>
        <title>Telnet Binary Transmission</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-BIN</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>NIC15389</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0027</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0856</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0857</doc-id>
        <title>Telnet Echo Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>TOPT-ECHO</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>NIC15390</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0028</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0857</doi>
    </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. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>TOPT-SUPP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>NIC15392</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0029</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0858</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0859</doc-id>
        <title>Telnet Status Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TOPT-STAT</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <obsoletes>
            <doc-id>RFC0651</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0030</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0859</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0860</doc-id>
        <title>Telnet Timing Mark Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-TIM</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>NIC16238</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0031</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0860</doi>
    </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. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>TOPT-EXTOP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>NIC16239</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0032</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0861</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0862</doc-id>
        <title>Echo Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>ECHO</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0020</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0862</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0863</doc-id>
        <title>Discard Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>DISCARD</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0021</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0863</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0864</doc-id>
        <title>Character Generator Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>CHARGEN</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0022</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc864</errata-url>
        <doi>10.17487/RFC0864</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>QUOTE</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0023</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc865</errata-url>
        <doi>10.17487/RFC0865</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0866</doc-id>
        <title>Active users</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>USERS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0024</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0866</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0867</doc-id>
        <title>Daytime Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>DAYTIME</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0025</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0867</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>TIME</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0026</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc868</errata-url>
        <doi>10.17487/RFC0868</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0869</doc-id>
        <title>Host Monitoring Protocol</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>December</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>HMP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0869</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This RFC documents the list of numbers assigned for networks, protocols, etc.  Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0870</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0871</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>TCP LAN</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0872</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0873</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0874</doi>
    </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>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0875</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0876</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1356</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0877</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0851</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0878</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0879</doc-id>
        <title>The TCP Maximum Segment Size and Related Topics</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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".</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6691</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc879</errata-url>
        <doi>10.17487/RFC0879</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This RFC identifies the documents specifying the official protocols used in the ARPA Internet.  Annotations identify any revisions or changes planned.  Obsoletes RFC 840.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0880</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC0897</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0881</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0882</doc-id>
        <title>Domain names: Concepts and facilities</title>
        <author>
            <name>P. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc882</errata-url>
        <doi>10.17487/RFC0882</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0883</doc-id>
        <title>Domain names: Implementation specification</title>
        <author>
            <name>P. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0883</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This RFC specifies a standard for the ARPA Internet community.  It specifies a method for exchanging terminal type information in the Telnet protocol.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0930</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0884</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>TOPT-EOR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0885</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0887</doc-id>
        <title>Resource Location Protocol</title>
        <author>
            <name>M. Accetta</name>
        </author>
        <date>
            <month>December</month>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>RLP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0887</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC0904</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0888</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc889</errata-url>
        <doi>10.17487/RFC0889</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>EGP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0890</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IP-DC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0044</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0891</doi>
    </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>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0905</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0892</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0893</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0894</doc-id>
        <title>A Standard for the Transmission of IP Datagrams over Ethernet Networks</title>
        <author>
            <name>C. Hornig</name>
        </author>
        <date>
            <month>April</month>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IP-E</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0041</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc894</errata-url>
        <doi>10.17487/RFC0894</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IP-EE</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0042</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0895</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0896</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0897</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0898</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0899</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0900</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0901</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0902</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0903</doc-id>
        <title>A 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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>RARP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0038</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0903</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>EGP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0827</doc-id>
            <doc-id>RFC0888</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0904</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>164</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0892</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0905</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0906</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0907</doc-id>
        <title>Host Access Protocol specification</title>
        <author>
            <name>Bolt Beranek and Newman Laboratories</name>
        </author>
        <date>
            <month>July</month>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>IP-WB</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC1221</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0040</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0907</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>RDP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC1151</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0908</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>135</page-count>
        <keywords>
            <kw>LDP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0909</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0910</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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).</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0911</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0912</doc-id>
        <title>Authentication service</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>September</month>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0931</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0912</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SFTP</kw>
            <kw>FTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0913</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>THINWIRE</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0914</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0915</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>RATP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc916</errata-url>
        <doi>10.17487/RFC0916</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0917</doc-id>
        <title>Internet subnets</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <date>
            <month>October</month>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc917</errata-url>
        <doi>10.17487/RFC0917</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0937</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc918</errata-url>
        <doi>10.17487/RFC0918</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0919</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0920</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0897</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0921</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0922</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0923</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0924</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0925</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>107</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0994</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0926</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-TACACS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0927</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0928</doi>
    </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>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>HFEP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0929</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0930</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0931</doc-id>
        <title>Authentication server</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>January</month>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0931</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0932</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-OM</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0933</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0934</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0935</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0936</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>POP2</kw>
            <kw>Post Office Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0918</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0937</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IRTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0938</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0939</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0940</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0941</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <abstract><p>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).</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0942</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0943</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0944</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1039</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0945</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-TLN</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0946</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0947</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1042</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0948</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0949</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Address</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0792</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6918</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0950</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BOOTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC1395</doc-id>
            <doc-id>RFC1497</doc-id>
            <doc-id>RFC1532</doc-id>
            <doc-id>RFC1542</doc-id>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc951</errata-url>
        <doi>10.17487/RFC0951</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0810</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1123</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc952</errata-url>
        <doi>10.17487/RFC0952</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>HOSTNAME</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0811</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0953</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>NICNAME</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0954</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0955</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0956</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc957</errata-url>
        <doi>10.17487/RFC0957</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0958</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0959</doc-id>
        <title>File Transfer Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>October</month>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <abstract><p>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.</p></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>
            <doc-id>RFC3659</doc-id>
            <doc-id>RFC5797</doc-id>
            <doc-id>RFC7151</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0009</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc959</errata-url>
        <doi>10.17487/RFC0959</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0960</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0961</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0962</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0963</doi>
    </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>
        <author>
            <name>T. Blumer</name>
        </author>
        <date>
            <month>November</month>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0964</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0965</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0988</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0966</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0967</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0968</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0998</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0969</doi>
    </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>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0970</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0971</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0972</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0973</doc-id>
        <title>Domain system changes and observations</title>
        <author>
            <name>P. Mockapetris</name>
        </author>
        <date>
            <month>January</month>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0973</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS-MX</kw>
        </keywords>
        <abstract><p>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.</p></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>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0974</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0975</doc-id>
        <title>Autonomous confederations</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>February</month>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0975</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC1137</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0976</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>NNTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3977</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0977</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0978</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0979</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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).</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0980</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0981</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0982</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1006</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0983</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC0993</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0984</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Requirements</kw>
            <kw>Internet</kw>
            <kw>gateways</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1009</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0985</doi>
    </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. Callon</name>
        </author>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>June</month>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1069</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0986</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2156</doc-id>
            <doc-id>RFC1327</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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0987</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0988</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0989</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0990</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0991</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0992</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0993</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <abstract><p>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).</p></abstract>
        <obsoletes>
            <doc-id>RFC0926</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc994</errata-url>
        <doi>10.17487/RFC0994</doi>
    </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>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0995</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0996</doc-id>
        <title>Statistics server</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>February</month>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>STATSRV</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0996</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0997</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>NETBLT</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0969</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0998</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC0999</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>149</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0999</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1000</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>NETBIOS</kw>
        </keywords>
        <abstract><p>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".</p></abstract>
        <is-also>
            <doc-id>STD0019</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1001</errata-url>
        <doi>10.17487/RFC1001</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>NETBIOS</kw>
        </keywords>
        <abstract><p>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".</p></abstract>
        <is-also>
            <doc-id>STD0019</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1002</errata-url>
        <doi>10.17487/RFC1002</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1003</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>COOKIE-JAR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1004</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1006</doc-id>
        <title>ISO Transport Service 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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TP-TCP</kw>
        </keywords>
        <abstract><p>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.</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1006</errata-url>
        <doi>10.17487/RFC1006</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1007</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1008</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1009</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1010</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0991</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6093</doc-id>
            <doc-id>RFC9293</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1011</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1012</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1013</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1014</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1015</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1016</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1017</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.  Distribution of this memo is unlimited.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1018</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1019</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <abstract><p>This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers.  This RFC obsoletes RFC-997.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1020</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>HEMS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1021</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1022</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1076</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1023</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1024</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1025</errata-url>
        <doi>10.17487/RFC1025</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2156</doc-id>
            <doc-id>RFC1327</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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1026</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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".</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1027</errata-url>
        <doi>10.17487/RFC1027</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>SGMP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1028</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>arp</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1029</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1030</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1031</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1032</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>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).</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1033</errata-url>
        <doi>10.17487/RFC1033</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1034</doc-id>
        <title>Domain names - concepts and facilities</title>
        <author>
            <name>P. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>DOMAIN</kw>
        </keywords>
        <abstract><p>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.</p></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>
            <doc-id>RFC4343</doc-id>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC4592</doc-id>
            <doc-id>RFC5936</doc-id>
            <doc-id>RFC8020</doc-id>
            <doc-id>RFC8482</doc-id>
            <doc-id>RFC8767</doc-id>
            <doc-id>RFC9471</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0013</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1034</errata-url>
        <doi>10.17487/RFC1034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1035</doc-id>
        <title>Domain names - implementation and specification</title>
        <author>
            <name>P. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>DOMAIN</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>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.</p></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>RFC2673</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>
            <doc-id>RFC4343</doc-id>
            <doc-id>RFC5936</doc-id>
            <doc-id>RFC5966</doc-id>
            <doc-id>RFC6604</doc-id>
            <doc-id>RFC7766</doc-id>
            <doc-id>RFC8482</doc-id>
            <doc-id>RFC8490</doc-id>
            <doc-id>RFC8767</doc-id>
            <doc-id>RFC9619</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0013</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1035</errata-url>
        <doi>10.17487/RFC1035</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0850</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5536</doc-id>
            <doc-id>RFC5537</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1036</errata-url>
        <doi>10.17487/RFC1036</doi>
    </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>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>NFILE</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1037</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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".</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1108</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1038</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0945</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1039</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1040</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TOPT-3270</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC6270</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1041</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IP-IEEE</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0948</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0043</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1042</errata-url>
        <doi>10.17487/RFC1042</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>TOPT-DATA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0732</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1043</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>IP-HC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0045</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1044</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>128</page-count>
        <keywords>
            <kw>VMTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1045</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1046</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1047</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This memo proposes an addition to the Bootstrap Protocol (BOOTP).  Comments and suggestions for improvements are sought.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1048</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>CONTENT</kw>
        </keywords>
        <abstract><p>This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1049</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>SUN-RPC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1057</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1050</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1201</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1051</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1052</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>TOPT-X.3</kw>
        </keywords>
        <abstract><p>This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1053</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1054</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IP-SLIP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0047</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1055</errata-url>
        <doi>10.17487/RFC1055</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>PCMAIL</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0993</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1056</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SUN-RPC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1050</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1057</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>RIP</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1058</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>NTPv1</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1059</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1060</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <abstract><p>This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1062</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1191</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1063</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1064</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1155</doc-id>
        </obsoleted-by>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1065</errata-url>
        <doi>10.17487/RFC1065</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1156</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1066</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1098</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1067</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1068</doi>
    </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. Callon</name>
        </author>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>February</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC0986</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1069</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1070</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum.  It is not a standard, but a set of useful implementation techniques.</p></abstract>
        <updated-by>
            <doc-id>RFC1141</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1071</errata-url>
        <doi>10.17487/RFC1071</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1323</doc-id>
            <doc-id>RFC2018</doc-id>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1072</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TOPT-NAWS</kw>
        </keywords>
        <abstract><p>This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1073</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1074</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IP-DVMRP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1075</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1023</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1076</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1077</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1078</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TOPT-TS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1079</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1372</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1080</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1225</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1081</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1082</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1100</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1083</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1084</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1085</doi>
    </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>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1086</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>Ethics</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract><p>This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1087</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IP-NETBIOS</kw>
        </keywords>
        <abstract><p>This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.</p></abstract>
        <is-also>
            <doc-id>STD0048</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1089</doc-id>
        <title>SNMP over Ethernet</title>
        <author>
            <name>M. Schoffstall</name>
        </author>
        <author>
            <name>C. Davin</name>
        </author>
        <author>
            <name>M. Fedor</name>
        </author>
        <author>
            <name>J. Case</name>
        </author>
        <date>
            <month>February</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4789</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1089</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1090</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TOPT-TERM</kw>
        </keywords>
        <abstract><p>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</p></abstract>
        <obsoletes>
            <doc-id>RFC0930</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1091</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1092</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1094</doc-id>
        <title>NFS: Network File System Protocol specification</title>
        <author>
            <name>B. Nowicki</name>
        </author>
        <date>
            <month>March</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>SUN-NFS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1813</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1094</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1189</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1095</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TOPT-XDL</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1096</doi>
    </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>1</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1097</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1098</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1099</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1083</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1130</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1100</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1101</doc-id>
        <title>DNS encoding of network names and other types</title>
        <author>
            <name>P. Mockapetris</name>
        </author>
        <date>
            <month>April</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1101</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1102</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1188</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1103</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1104</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems.  Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1163</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1105</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1106</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1107</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPSO</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1038</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1108</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1109</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This memo comments on the TCP Big Window option described in RFC 1106.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1110</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This RFC specifies a standard for the Internet community.  Authors of RFCs are expected to adopt and implement this standard.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1111</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IGMP</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>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]</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1112</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]</p></abstract>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1113</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1422</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1114</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1423</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1115</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1184</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1116</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <abstract><p>This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1117</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1118</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>NTPv2</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC0958</doc-id>
            <doc-id>RFC1059</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1305</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1120</doc-id>
        <title>Internet Activities Board</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>September</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1160</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1120</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1121</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>116</page-count>
        <keywords>
            <kw>applicability</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC0793</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1349</doc-id>
            <doc-id>RFC4379</doc-id>
            <doc-id>RFC5884</doc-id>
            <doc-id>RFC6093</doc-id>
            <doc-id>RFC6298</doc-id>
            <doc-id>RFC6633</doc-id>
            <doc-id>RFC6864</doc-id>
            <doc-id>RFC8029</doc-id>
            <doc-id>RFC9293</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0003</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1122</errata-url>
        <doi>10.17487/RFC1122</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>98</page-count>
        <keywords>
            <kw>applicability</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC0822</doc-id>
            <doc-id>RFC0952</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1349</doc-id>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC5321</doc-id>
            <doc-id>RFC5966</doc-id>
            <doc-id>RFC7766</doc-id>
            <doc-id>RFC9210</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0003</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1123</errata-url>
        <doi>10.17487/RFC1123</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1124</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1125</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1126</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1127</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1128</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <keywords>
            <kw>NTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1119</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1129</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).</p></abstract>
        <obsoletes>
            <doc-id>RFC1100</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1140</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1131</doc-id>
        <title>OSPF specification</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>October</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>1</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1247</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1131</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IP-IPX</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>STD0049</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1132</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1133</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1171</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1134</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1135</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1136</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0976</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1137</doi>
    </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>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2156</doc-id>
            <doc-id>RFC1327</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1026</doc-id>
            <doc-id>RFC0987</doc-id>
            <doc-id>RFC0822</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1148</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1138</errata-url>
        <doi>10.17487/RFC1138</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>osigen</wg_acronym>
        <doi>10.17487/RFC1139</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1130</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1200</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1140</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1141</errata-url>
        <doi>10.17487/RFC1141</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>517</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Routing</kw>
            <kw>ISO</kw>
        </keywords>
        <abstract><p>This RFC is a republication of ISO DP 10589 as a service to the Internet community.  This is not an Internet standard.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7142</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1142</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1143</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>IP-CMPRS</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1144</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1146</doc-id>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1145</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>TCP-ACO</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1145</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1146</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>177</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1470</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>noctools</wg_acronym>
        <doi>10.17487/RFC1147</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2156</doc-id>
            <doc-id>RFC1327</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1026</doc-id>
            <doc-id>RFC0987</doc-id>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC0822</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1148</errata-url>
        <doi>10.17487/RFC1148</doi>
    </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>1</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>avian</kw>
            <kw>carrier</kw>
            <kw>april</kw>
            <kw>fools</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC2549</doc-id>
            <doc-id>RFC6214</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1149</errata-url>
        <doi>10.17487/RFC1149</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6360</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1150</errata-url>
        <doi>10.17487/RFC1150</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>RDP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0908</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1151</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1152</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>DMF-MAIL</kw>
        </keywords>
        <abstract><p>This memo describes the de facto standard Digest Message Format.  This is an elective experimental protocol.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1153</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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).</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1505</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1154</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SMI</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1065</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0016</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1155</errata-url>
        <doi>10.17487/RFC1155</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>MIB-I</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1066</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1156</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1098</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1157</errata-url>
        <doi>10.17487/RFC1157</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>133</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1213</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1158</errata-url>
        <doi>10.17487/RFC1158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1159</doc-id>
        <title>Message Send Protocol</title>
        <author>
            <name>R. Nelson</name>
        </author>
        <date>
            <month>June</month>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1312</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1160</doc-id>
        <title>Internet Activities Board</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>May</month>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1120</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1160</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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,</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1418</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1161</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1238</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1162</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1163</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1268</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1164</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>NTP-OSI</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1165</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>182</page-count>
        <abstract><p>This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.</p></abstract>
        <obsoletes>
            <doc-id>RFC1117</doc-id>
            <doc-id>RFC1062</doc-id>
            <doc-id>RFC1020</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5737</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1166</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1167</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1168</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1169</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1170</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ppp</wg_acronym>
        <doi>10.17487/RFC1171</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ppp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1172</errata-url>
        <doi>10.17487/RFC1172</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1173</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1174</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>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.]</p></abstract>
        <is-also>
            <doc-id>FYI0003</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>userdoc</wg_acronym>
        <doi>10.17487/RFC1175</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>IMAP2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1064</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1176</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>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.]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1206</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1177</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.]</p></abstract>
        <is-also>
            <doc-id>FYI0005</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1178</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>LPDP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1179</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1180</errata-url>
        <doi>10.17487/RFC1180</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1181</doi>
    </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. Everhart</name>
        </author>
        <author>
            <name>L. Mamakos</name>
        </author>
        <author>
            <name>R. Ullmann</name>
        </author>
        <author>
            <name>P. Mockapetris</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>DNS-RR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5395</doc-id>
            <doc-id>RFC5864</doc-id>
            <doc-id>RFC6195</doc-id>
            <doc-id>RFC6895</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1183</errata-url>
        <doi>10.17487/RFC1183</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>TOPT-LINE</kw>
        </keywords>
        <abstract><p>This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol.  It obsoletes RFC 1116. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1116</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1184</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1323</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1185</errata-url>
        <doi>10.17487/RFC1185</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1320</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1186</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SNMP-BULK</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1187</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1103</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>fddi</wg_acronym>
        <doi>10.17487/RFC1188</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>CMOT</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1095</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>oim</wg_acronym>
        <doi>10.17487/RFC1189</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>148</page-count>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>cip</wg_acronym>
        <doi>10.17487/RFC1190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1191</doc-id>
        <title>Path MTU discovery</title>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>November</month>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IP-MTU</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1063</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1191</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1192</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1193</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1194</doi>
    </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. Callon</name>
        </author>
        <date>
            <month>December</month>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>IS-IS</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC1349</doc-id>
            <doc-id>RFC5302</doc-id>
            <doc-id>RFC5304</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1195</errata-url>
        <doi>10.17487/RFC1195</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1196</doi>
    </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>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1197</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0006</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1198</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Summary</kw>
            <kw>RFC</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1199</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1140</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1250</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1200</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IP-ARC</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1051</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0046</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1201</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>DAS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1202</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>IMAP3</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1064</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1203</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MPP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1205</doc-id>
        <title>5250 Telnet interface</title>
        <author>
            <name>P. Chmielewski</name>
        </author>
        <date>
            <month>February</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC2877</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1205</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1206</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0007</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1208</doc-id>
        <title>A Glossary of Networking Terms</title>
        <author>
            <name>O.J. Jacobsen</name>
        </author>
        <author>
            <name>D.C. Lynch</name>
        </author>
        <date>
            <month>March</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1209</doc-id>
        <title>The Transmission of IP Datagrams over the SMDS Service</title>
        <author>
            <name>D. Piscitello</name>
        </author>
        <author>
            <name>J. Lawrence</name>
        </author>
        <date>
            <month>March</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IP-SMDS</kw>
            <kw>Switched Multi-megabit Data Service</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <is-also>
            <doc-id>STD0052</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>smds</wg_acronym>
        <doi>10.17487/RFC1209</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1210</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1211</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Concise-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <is-also>
            <doc-id>STD0016</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1212</doi>
    </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. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>MIB-II</kw>
        </keywords>
        <abstract><p>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]</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1213</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>OIM-MIB-II</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>oim</wg_acronym>
        <doi>10.17487/RFC1214</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SNMP-TRAPS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1215</doi>
    </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>1</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1216</doi>
    </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>1</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1217</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1218</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SUBNETASGN</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1219</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1638</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1220</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>HAP2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC0907</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1221</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1222</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>OSI-HYPER</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1223</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>ALERTS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>alertman</wg_acronym>
        <doi>10.17487/RFC1224</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1225</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>IP-AX.25</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1226</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SNMP-MUX</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1227</errata-url>
        <doi>10.17487/RFC1227</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1592</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1228</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1229</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>802.4-MIP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC1239</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1230</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1231</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <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>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1232</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1233</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPX-IP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1234</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>CFDP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1235</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IP-X.121</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1236</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <abstract><p>This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1629</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>osinsap</wg_acronym>
        <doi>10.17487/RFC1237</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>CLNS-MIB</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1162</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1238</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>STD-MIBs</kw>
        </keywords>
        <abstract><p>This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]</p></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>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1239</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>OSI-UDP</kw>
        </keywords>
        <abstract><p>This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1240</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IN-ENCAP</kw>
        </keywords>
        <abstract><p>This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1241</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC6201</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC1242</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1742</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>appleip</wg_acronym>
        <doi>10.17487/RFC1243</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2196</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1245</doc-id>
        <title>OSPF Protocol Analysis</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>July</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>routing</kw>
            <kw>TOS</kw>
            <kw>LSA</kw>
            <kw>flooding</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1246</doc-id>
            <doc-id>RFC1247</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1245</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>routing</kw>
            <kw>MIB</kw>
            <kw>experience</kw>
            <kw>testing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1245</doc-id>
            <doc-id>RFC1247</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1247</doc-id>
        <title>OSPF Version 2</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>July</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>189</page-count>
        <keywords>
            <kw>equal-cost</kw>
            <kw>multipath</kw>
            <kw>link state</kw>
            <kw>LSA</kw>
        </keywords>
        <abstract><p>This memo documents version 2 of the OSPF protocol.  OSPF is a link- state based routing protocol. [STANDARDS-TRACK]</p></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>RFC1245</doc-id>
            <doc-id>RFC1246</doc-id>
        </see-also>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1247</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>MIB</kw>
            <kw>routing</kw>
            <kw>network management</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1248</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DIXIE</kw>
            <kw>DIXIE</kw>
            <kw>protocol</kw>
            <kw>directory services</kw>
            <kw>X.500</kw>
            <kw>DAP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1202</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1249</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>standards</kw>
            <kw>protocol</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>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.</p></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>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1250</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IESG</kw>
            <kw>IRSG</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1336</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1251</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>MIB</kw>
            <kw>routing</kw>
            <kw>network management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1248</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1253</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC1245</doc-id>
            <doc-id>RFC1247</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1252</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1252</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1850</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC1245</doc-id>
            <doc-id>RFC1246</doc-id>
            <doc-id>RFC1247</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1253</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>gateway</kw>
            <kw>congestion</kw>
            <kw>SQ</kw>
            <kw>source quench</kw>
            <kw>fiar queueing</kw>
            <kw>random drop</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcc</wg_acronym>
        <doi>10.17487/RFC1254</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>naming</kw>
            <kw>NADF</kw>
            <kw>X.500</kw>
            <kw>directory services</kw>
            <kw>c=us</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1255</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>rdisc</wg_acronym>
        <doi>10.17487/RFC1256</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1258</doc-id>
        <title>BSD Rlogin</title>
        <author>
            <name>B. Kantor</name>
        </author>
        <date>
            <month>September</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1282</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1258</errata-url>
        <doi>10.17487/RFC1258</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>NREN</kw>
            <kw>test-bed</kw>
            <kw>network policy</kw>
        </keywords>
        <abstract><p>This memo discusses the background and importance of NREN.  This memo provides information for the Internet community.  It does not specify an Internet standard.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1259</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>NIC</kw>
            <kw>transition</kw>
        </keywords>
        <abstract><p>This memo outlines the transition of NIC Services.  This memo provides information for the Internet community.  It does not specify an Internet standard.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1261</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1262</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1263</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4794</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC1264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1265</doc-id>
        <title>BGP Protocol Analysis</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1265</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1266</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>BGP3</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1163</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1267</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>BGP3</kw>
        </keywords>
        <abstract><p>This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1268</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>BGP-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4273</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1270</doc-id>
        <title>SNMP Communications Services</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>October</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1270</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC1271</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>acct</wg_acronym>
        <doi>10.17487/RFC1272</doi>
    </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>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1273</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>Naming</kw>
        </keywords>
        <abstract><p>This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4524</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1274</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1275</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1276</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>address ISO OSI</kw>
        </keywords>
        <abstract><p>This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1277</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>OSI</kw>
            <kw>ASN.1</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1278</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>naming</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1279</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1250</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1360</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1280</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>security</kw>
            <kw>privacy</kw>
            <kw>protection</kw>
            <kw>guideline</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>spwg</wg_acronym>
        <doi>10.17487/RFC1281</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BSD Login</kw>
            <kw>Unix</kw>
            <kw>remote-login</kw>
            <kw>remote-logon</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1258</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1282</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ISO</kw>
            <kw>Management</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1418</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1283</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1398</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1284</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>FDDI-MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>MIB</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC1512</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>fddimib</wg_acronym>
        <doi>10.17487/RFC1285</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <doi>10.17487/RFC1286</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1287</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>FINGER</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1288</errata-url>
        <doi>10.17487/RFC1288</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>protocol</kw>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1559</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>decnetiv</wg_acronym>
        <doi>10.17487/RFC1289</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>SIGUCCS</kw>
            <kw>User Services</kw>
            <kw>Help</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1402</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1290</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>statistics</kw>
            <kw>connectivity</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1291</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>103</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1632</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>disi</wg_acronym>
        <doi>10.17487/RFC1292</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>ARP</kw>
            <kw>DLCI</kw>
        </keywords>
        <abstract><p>This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2390</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>iplpdn</wg_acronym>
        <doi>10.17487/RFC1293</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>iplpdn</wg_acronym>
        <doi>10.17487/RFC1294</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>NADF-265</kw>
            <kw>NADF</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1417</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1295</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>statistics</kw>
            <kw>ZONE</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1296</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>problems</kw>
            <kw>tracking</kw>
            <kw>operations</kw>
            <kw>NOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>ucp</wg_acronym>
        <doi>10.17487/RFC1297</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1420</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1298</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1299</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>poem</kw>
        </keywords>
        <abstract><p>Poem.  This memo provides information for the Internet community.  It does not specify an Internet standard.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1300</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1301</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NISI</kw>
            <kw>NIC</kw>
            <kw>User Services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0012</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>nisi</wg_acronym>
        <doi>10.17487/RFC1302</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>Network Management,</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1155</doc-id>
            <doc-id>RFC1157</doc-id>
            <doc-id>RFC1212</doc-id>
            <doc-id>RFC1213</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1303</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Tesink</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Standard</kw>
            <kw>MIB</kw>
            <kw>Network Management</kw>
            <kw>SMDS</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1694</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmp</wg_acronym>
        <doi>10.17487/RFC1304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1305</doc-id>
        <title>Network Time Protocol (Version 3) Specification, Implementation and Analysis</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <keywords>
            <kw>NTPV3</kw>
            <kw>NTP</kw>
        </keywords>
        <abstract><p>This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation.</p></abstract>
        <obsoletes>
            <doc-id>RFC0958</doc-id>
            <doc-id>RFC1059</doc-id>
            <doc-id>RFC1119</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5905</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1305</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>WAN</kw>
            <kw>Wide Area Net</kw>
            <kw>FDDI</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1306</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DSLCP</kw>
            <kw>Experimental Protocol</kw>
            <kw>T3</kw>
            <kw>FDDI</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1307</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0013</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>disi</wg_acronym>
        <doi>10.17487/RFC1308</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0014</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>disi</wg_acronym>
        <doi>10.17487/RFC1309</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1602</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1310</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>new</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1311</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MSP2</kw>
            <kw>MSP</kw>
            <kw>talk</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1159</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1312</doi>
    </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>1</day>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1313</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>NETFAX</kw>
            <kw>TIFF</kw>
            <kw>facsimile</kw>
        </keywords>
        <abstract><p>This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>netfax</wg_acronym>
        <doi>10.17487/RFC1314</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2115</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>iplpdn</wg_acronym>
        <doi>10.17487/RFC1315</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1658</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>charmib</wg_acronym>
        <doi>10.17487/RFC1316</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1659</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>charmib</wg_acronym>
        <doi>10.17487/RFC1317</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1660</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>charmib</wg_acronym>
        <doi>10.17487/RFC1318</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6149</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1319</errata-url>
        <doi>10.17487/RFC1319</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MD4</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1186</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6150</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1320</errata-url>
        <doi>10.17487/RFC1320</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>security</kw>
            <kw>signature</kw>
            <kw>eneryption</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC6151</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1321</errata-url>
        <doi>10.17487/RFC1321</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>path</kw>
            <kw>vector</kw>
            <kw>routing</kw>
            <kw>source</kw>
            <kw>demand</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bgp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1322</errata-url>
        <doi>10.17487/RFC1322</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>TCP-EXT</kw>
            <kw>options</kw>
            <kw>PAWS</kw>
            <kw>window</kw>
            <kw>scale</kw>
            <kw>window scale</kw>
            <kw>Protect Against Wrapped Sequence numbers</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1072</doc-id>
            <doc-id>RFC1185</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7323</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcplw</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1323</errata-url>
        <doi>10.17487/RFC1323</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>talk</kw>
            <kw>real time</kw>
            <kw>chat</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1324</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>documentation</kw>
            <kw>help</kw>
            <kw>information</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1325</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>protocol</kw>
            <kw>layering</kw>
            <kw>wrapping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1326</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>113</page-count>
        <keywords>
            <kw>Electronic-mail,Message handling systems</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1327</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Electronic-mail</kw>
            <kw>message handling systems,mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1328</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1329</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>87</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1330</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>serial line</kw>
            <kw>IP over serial</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1331</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>PPP-IPCP</kw>
            <kw>serial line</kw>
            <kw>IP over serial</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1332</errata-url>
        <doi>10.17487/RFC1332</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>serial line</kw>
            <kw>IP over serial</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1989</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1333</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>point</kw>
            <kw>serial</kw>
            <kw>line</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract><p>This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1994</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1334</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1335</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <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><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1336</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TCP protocol</kw>
            <kw>protocol state</kw>
            <kw>graceful close</kw>
            <kw>reset</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1337</errata-url>
        <doi>10.17487/RFC1337</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>internet address</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1519</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1338</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>RMCP</kw>
            <kw>email</kw>
            <kw>remote mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1339</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>139</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1060</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1700</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1340</errata-url>
        <doi>10.17487/RFC1340</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>EMail</kw>
            <kw>Multimedia</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1521</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC1341</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>EMail</kw>
            <kw>Character Sets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1522</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC1342</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>EMail</kw>
            <kw>Multimedia</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1343</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>EMail</kw>
            <kw>Forwarding</kw>
            <kw>Relaying</kw>
            <kw>Fragmentation</kw>
            <kw>Multimedia</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1344</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>103</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1345</errata-url>
        <doi>10.17487/RFC1345</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1346</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1347</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>domain names</kw>
            <kw>CLNP</kw>
            <kw>resource records</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1348</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>TOS</kw>
            <kw>TOS</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rreq</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1349</errata-url>
        <doi>10.17487/RFC1349</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TFTP</kw>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract><p>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]</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1350</errata-url>
        <doi>10.17487/RFC1350</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>SNMP-ADMIN</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>snmpsec</wg_acronym>
        <doi>10.17487/RFC1351</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>SNMP-SEC</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>snmpsec</wg_acronym>
        <doi>10.17487/RFC1352</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>SNMP-PARTY-MIB</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>snmpsec</wg_acronym>
        <doi>10.17487/RFC1353</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Route</kw>
            <kw>Table</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2096</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rreq</wg_acronym>
        <doi>10.17487/RFC1354</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>NIC</kw>
            <kw>data</kw>
            <kw>privacy</kw>
            <kw>accuracy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0015</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>nisi</wg_acronym>
        <doi>10.17487/RFC1355</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IP-X.25</kw>
            <kw>IP</kw>
            <kw>on</kw>
            <kw>X.25</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC0877</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>iplpdn</wg_acronym>
        <doi>10.17487/RFC1356</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>library</kw>
            <kw>technical</kw>
            <kw>reports</kw>
            <kw>email</kw>
            <kw>services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1807</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1357</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ISOC</kw>
            <kw>Internet</kw>
            <kw>Society</kw>
            <kw>IETF</kw>
            <kw>IRTF</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1601</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1358</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>access</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0016</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1359</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <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>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1360</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Clocks</kw>
            <kw>Synchronization</kw>
            <kw>NTP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1361</errata-url>
        <doi>10.17487/RFC1361</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IPX on X.25</kw>
            <kw>IPX on PPP</kw>
            <kw>IPX on Frame Relay</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1634</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1362</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1363</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1364</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>class F addresses</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1365</errata-url>
        <doi>10.17487/RFC1365</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>tables</kw>
            <kw>allocation</kw>
            <kw>registry</kw>
            <kw>IR</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1466</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1366</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>tables</kw>
            <kw>allocation</kw>
            <kw>registry</kw>
            <kw>IR</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1467</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1367</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>hub</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1516</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC1368</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>management</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>ethermib</wg_acronym>
        <doi>10.17487/RFC1369</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1370</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>recommendation</kw>
            <kw>interior</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC1371</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TOPT-RFC</kw>
            <kw>terminal</kw>
            <kw>access</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1080</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1372</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1373</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2834</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1374</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>network</kw>
            <kw>numbers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1375</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>point</kw>
            <kw>DNA</kw>
            <kw>DDCMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1762</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1376</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP-OSINLCP</kw>
            <kw>point</kw>
            <kw>open</kw>
            <kw>systems</kw>
            <kw>interconnection</kw>
        </keywords>
        <abstract><p>This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1377</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PPP-ATCP</kw>
            <kw>point</kw>
        </keywords>
        <abstract><p>This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1378</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1644</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1379</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>ROAD</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC1380</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>SNMP-LAPB</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>x25mib</wg_acronym>
        <doi>10.17487/RFC1381</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>SNMP-X.25</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>x25mib</wg_acronym>
        <doi>10.17487/RFC1382</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DNS-IP</kw>
        </keywords>
        <abstract><p>Potential solutions to the routing explosion.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1383</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>Multinational</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1384</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>addressing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6814</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1385</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>top-level</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1480</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1386</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1721</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC1387</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract><p>This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC1388</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RIP-2</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1724</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC1389</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IP-FDDI</kw>
            <kw>IEEE</kw>
            <kw>802</kw>
            <kw>MAC</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <is-also>
            <doc-id>STD0036</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>fddi</wg_acronym>
        <doi>10.17487/RFC1390</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>meetings</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1539</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1391</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1983</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>userglos</wg_acronym>
        <doi>10.17487/RFC1392</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TRACE-IP</kw>
            <kw>ICMP</kw>
            <kw>MTU</kw>
            <kw>Line</kw>
            <kw>Speed</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6814</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1393</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Country</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1394</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TAGS</kw>
        </keywords>
        <abstract><p>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).</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1395</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>IESG</kw>
            <kw>ISOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1396</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1397</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>ethermib</wg_acronym>
        <doi>10.17487/RFC1398</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1399</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>INTERNIC IR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1400</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Domain Name</kw>
            <kw>Milnet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1401</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>information</kw>
            <kw>introduction</kw>
            <kw>SIGUCCS</kw>
            <kw>User Services</kw>
            <kw>Help</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1402</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>BGP-OSPF</kw>
            <kw>border gateway protocol</kw>
            <kw>open shortest path first routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1364</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1403</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>Operations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1857</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>opstat</wg_acronym>
        <doi>10.17487/RFC1404</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>EMail</kw>
            <kw>822</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2162</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>x400ops</wg_acronym>
        <doi>10.17487/RFC1405</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Watt</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>DS1/E1-MIB</kw>
            <kw>T1</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trunkmib</wg_acronym>
        <doi>10.17487/RFC1406</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>DS3/E3-MIB</kw>
            <kw>T3</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trunkmib</wg_acronym>
        <doi>10.17487/RFC1407</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TOPT-ENVIR</kw>
            <kw>Negotiation</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC1571</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1408</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>security</kw>
        </keywords>
        <abstract><p>This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1416</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1409</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>proposed</kw>
            <kw>draft</kw>
            <kw>experimental</kw>
            <kw>informational</kw>
            <kw>historic</kw>
            <kw>full</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).</p></abstract>
        <obsoletes>
            <doc-id>RFC1360</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1500</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1410</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TEL-KER</kw>
            <kw>Security</kw>
            <kw>option</kw>
        </keywords>
        <abstract><p>This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1411</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>TEL-SPX</kw>
            <kw>Security</kw>
            <kw>option</kw>
        </keywords>
        <abstract><p>This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1412</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IDENT</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract><p>The Identification Protocol was formerly called the Authentication Server Protocol.  It has been renamed to better reflect its function. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC0931</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ident</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1413</errata-url>
        <doi>10.17487/RFC1413</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IDENT-MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ident</wg_acronym>
        <doi>10.17487/RFC1414</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>FTAM</kw>
            <kw>transfer</kw>
            <kw>ISO</kw>
            <kw>OSI</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1415</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TOPT-AUTH</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1416</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1417</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>SNMP-OSI</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1161</doc-id>
            <doc-id>RFC1283</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mpsnmp</wg_acronym>
        <doi>10.17487/RFC1418</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>SNMP-AT</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mpsnmp</wg_acronym>
        <doi>10.17487/RFC1419</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>SNMP-IPX</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1298</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mpsnmp</wg_acronym>
        <doi>10.17487/RFC1420</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>PEM-ENC</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1113</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <doi>10.17487/RFC1421</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>PEM-CKM</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract><p>This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1114</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <doi>10.17487/RFC1422</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>PEM-ALG</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1115</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <doi>10.17487/RFC1423</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>PEM-KEY</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <doi>10.17487/RFC1424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1425</doc-id>
        <title>SMTP Service Extensions</title>
        <author>
            <name>J. Klensin</name>
        </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1651</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1426</doc-id>
        <title>SMTP Service Extension for 8bit-MIMEtransport</title>
        <author>
            <name>J. Klensin</name>
        </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1652</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1427</doc-id>
        <title>SMTP Service Extension for Message Size Declaration</title>
        <author>
            <name>J. Klensin</name>
        </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1653</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1427</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1428</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>LISTSERV</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1429</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>X.500</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1430</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Directory User Agent</kw>
            <kw>Measurement</kw>
            <kw>Statistics</kw>
            <kw>Survey</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1431</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>bibiography</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1432</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DIR-ARP</kw>
            <kw>public networks</kw>
            <kw>SMDS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>iplpdn</wg_acronym>
        <doi>10.17487/RFC1433</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IBM</kw>
            <kw>SNA</kw>
            <kw>DLS</kw>
            <kw>SSP</kw>
            <kw>NetBIos</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1795</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1434</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>Maximum</kw>
            <kw>Transmission</kw>
            <kw>Unit</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC1435</doi>
    </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. Alberti</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>GOPHER</kw>
            <kw>information</kw>
            <kw>locating</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1436</errata-url>
        <doi>10.17487/RFC1436</doi>
    </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>1</day>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>life form</kw>
            <kw>Matter</kw>
            <kw>transport</kw>
            <kw>Sentient</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1437</doi>
    </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>1</day>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>process</kw>
            <kw>policy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1438</errata-url>
        <doi>10.17487/RFC1438</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>names</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1439</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SIFT</kw>
            <kw>UFT</kw>
            <kw>Send</kw>
            <kw>FTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1440</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SNMPv2</kw>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1441</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>SMI</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1902</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1442</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1903</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1443</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1904</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1444</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>snmpsec</wg_acronym>
        <doi>10.17487/RFC1445</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>snmpsec</wg_acronym>
        <doi>10.17487/RFC1446</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>snmpsec</wg_acronym>
        <doi>10.17487/RFC1447</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1905</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1448</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1906</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1449</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1907</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1450</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1451</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1908</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1452</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>XTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1453</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>PIP</kw>
            <kw>TUBA</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1454</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TOS-LS</kw>
            <kw>TOS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2474</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1455</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Character</kw>
            <kw>Set</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1456</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1457</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Real-Time</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1458</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>IRCP</kw>
            <kw>IRC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC2810</doc-id>
            <doc-id>RFC2811</doc-id>
            <doc-id>RFC2812</doc-id>
            <doc-id>RFC2813</doc-id>
            <doc-id>RFC7194</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1459</errata-url>
        <doi>10.17487/RFC1459</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Email</kw>
        </keywords>
        <abstract><p>This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1460</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>X25-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>x25mib</wg_acronym>
        <doi>10.17487/RFC1461</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Introduction</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0020</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>uswg</wg_acronym>
        <doi>10.17487/RFC1462</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0019</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>userdoc2</wg_acronym>
        <doi>10.17487/RFC1463</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>TXT</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1464</errata-url>
        <doi>10.17487/RFC1464</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>X400</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>x400ops</wg_acronym>
        <doi>10.17487/RFC1465</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>CIDR</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1466</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>tables</kw>
            <kw>allocation</kw>
            <kw>registry</kw>
            <kw>IR</kw>
            <kw>IANA</kw>
            <kw>classless</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1367</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1467</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Set</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC1468</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IP-TR-MC</kw>
            <kw>802.2</kw>
            <kw>802.5</kw>
        </keywords>
        <abstract><p>This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1469</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>192</page-count>
        <keywords>
            <kw>NOCTOOLS</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>noctool2</wg_acronym>
        <doi>10.17487/RFC1470</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>PPP/LCP MIB</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1471</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PPP/SEC MIB</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1472</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP/IP MIB</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1473</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>PPP/Bridge</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1474</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>TP-IX</kw>
            <kw>IPv7</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6814</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tpix</wg_acronym>
        <doi>10.17487/RFC1475</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>RAP</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tpix</wg_acronym>
        <doi>10.17487/RFC1476</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>Policy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idpr</wg_acronym>
        <doi>10.17487/RFC1477</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>IDPR-ARCH</kw>
            <kw>IDPR</kw>
        </keywords>
        <abstract><p>We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idpr</wg_acronym>
        <doi>10.17487/RFC1478</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>108</page-count>
        <keywords>
            <kw>IDPR</kw>
        </keywords>
        <abstract><p>We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idpr</wg_acronym>
        <doi>10.17487/RFC1479</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>top-level</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1386</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1480</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>CIDR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1481</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CIDR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>bgpdepl</wg_acronym>
        <doi>10.17487/RFC1482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1483</doc-id>
        <title>Multiprotocol Encapsulation over ATM Adaptation Layer 5</title>
        <author>
            <name>J. Heinanen</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ATM-ENCAP</kw>
            <kw>IP</kw>
            <kw>AAL5</kw>
            <kw>over</kw>
        </keywords>
        <abstract><p>This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2684</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipatm</wg_acronym>
        <doi>10.17487/RFC1483</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1484</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1485</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>electronic mail</kw>
            <kw>facsimile</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1486</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>DAP</kw>
            <kw>interactive access</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1487</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1778</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1488</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1489</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>IP</kw>
            <kw>over</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>iplpdn</wg_acronym>
        <doi>10.17487/RFC1490</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>directory</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0021</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC1491</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>TACACS</kw>
            <kw>Terminal</kw>
            <kw>Server</kw>
            <kw>TAC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1492</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>BRIDGE-MIB</kw>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1286</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4188</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <doi>10.17487/RFC1493</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Equiv</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mimemhs</wg_acronym>
        <doi>10.17487/RFC1494</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mimemhs</wg_acronym>
        <doi>10.17487/RFC1495</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>HARPOON</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mimemhs</wg_acronym>
        <doi>10.17487/RFC1496</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TAGS</kw>
            <kw>Boot</kw>
        </keywords>
        <abstract><p>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).</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1497</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>NAMES</kw>
            <kw>Addresses</kw>
            <kw>Routes</kw>
            <kw>Objects</kw>
            <kw>Nodes</kw>
            <kw>Paths</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1498</errata-url>
        <doi>10.17487/RFC1498</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1499</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1410</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1540</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1500</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1501</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>x400ops</wg_acronym>
        <doi>10.17487/RFC1502</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1503</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>AVRP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1504</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>EHF-MAIL</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1154</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1505</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>822</kw>
            <kw>email</kw>
            <kw>RTR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1506</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>119</page-count>
        <keywords>
            <kw>DASS</kw>
            <kw>CAT</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC1507</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>CAT,GSS,API</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2078</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC1508</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>GSSAPI</kw>
            <kw>CAT,GSS</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2744</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC1509</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>112</page-count>
        <keywords>
            <kw>KERBEROS</kw>
            <kw>CAT</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4120</doc-id>
            <doc-id>RFC6649</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1510</errata-url>
        <doi>10.17487/RFC1510</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>CAT,Security</kw>
        </keywords>
        <abstract><p>This memo provides information for the Internet community.  It does not specify an Internet standard.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1511</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>FDDI-MIB</kw>
            <kw>MIB</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1285</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>fddimib</wg_acronym>
        <doi>10.17487/RFC1512</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>Monitoring</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]</p></abstract>
        <updates>
            <doc-id>RFC1271</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC1513</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>HOST-MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2790</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>hostmib</wg_acronym>
        <doi>10.17487/RFC1514</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3636</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC1515</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC1516</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>CIDR</kw>
            <kw>Address</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1517</errata-url>
        <doi>10.17487/RFC1517</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>CIDR-ARCH</kw>
            <kw>Classless</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1518</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>CIDR-STRA</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1338</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4632</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1519</errata-url>
        <doi>10.17487/RFC1519</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Classless</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1520</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>email</kw>
            <kw>multimedia</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC1521</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>email</kw>
            <kw>character</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1522</errata-url>
        <doi>10.17487/RFC1522</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>email</kw>
            <kw>mail</kw>
            <kw>richtext</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC1523</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>email</kw>
            <kw>mailcap</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1524</errata-url>
        <doi>10.17487/RFC1524</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SRB-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1286</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <doi>10.17487/RFC1525</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>NSAP</kw>
            <kw>Address</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tuba</wg_acronym>
        <doi>10.17487/RFC1526</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1527</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>REM-PRINT</kw>
            <kw>FAX</kw>
            <kw>Facsimile</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1486</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9121</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1528</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>FAX</kw>
            <kw>Facsimile</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1486</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1529</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>FAX</kw>
            <kw>Facsimile</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1530</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>DHCP</kw>
        </keywords>
        <abstract><p>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1541</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1531</errata-url>
        <doi>10.17487/RFC1531</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>BOOTP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC1532</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract><p>This document specifies the current set of DHCP options. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1533</errata-url>
        <doi>10.17487/RFC1533</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>DHCP-BOOTP</kw>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract><p>DHCP provides a superset of the functions provided by BOOTP.  This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]</p></abstract>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1534</errata-url>
        <doi>10.17487/RFC1534</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1535</errata-url>
        <doi>10.17487/RFC1535</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC9210</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dns</wg_acronym>
        <doi>10.17487/RFC1536</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1912</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dns</wg_acronym>
        <doi>10.17487/RFC1537</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ADSNA-IP</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1538</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Introduction</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1539</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1500</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1600</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1540</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>DHCP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1541</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>BOOTP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1542</errata-url>
        <doi>10.17487/RFC1542</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Request</kw>
            <kw>For</kw>
            <kw>Comment</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1543</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>EMail</kw>
            <kw>Integrity</kw>
            <kw>MIC</kw>
            <kw>Digest</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1864</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC1544</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>File Transfer</kw>
            <kw>PORT</kw>
            <kw>PASV</kw>
            <kw>LPRT</kw>
            <kw>LPSV</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1639</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1545</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Resource Location</kw>
            <kw>Multicasting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC1546</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1547</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1548</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>point</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract><p>This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1662</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1549</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1550</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Internetworking</kw>
            <kw>Packet</kw>
            <kw>Exchange</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1634</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1551</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPXCP</kw>
            <kw>IPX</kw>
            <kw>point</kw>
            <kw>serial</kw>
            <kw>line</kw>
            <kw>link</kw>
        </keywords>
        <abstract><p>This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1552</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>CIPX</kw>
            <kw>Internetworking</kw>
            <kw>Packet</kw>
            <kw>Exchange</kw>
        </keywords>
        <abstract><p>This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1553</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Character Set</kw>
            <kw>Japanese</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1554</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Character Set</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1555</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Character Set</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1556</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Character Set</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1557</errata-url>
        <doi>10.17487/RFC1557</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1960</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1558</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>DECNET-MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1289</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>decnetiv</wg_acronym>
        <doi>10.17487/RFC1559</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Architecture</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1560</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>CLNP-TUBA</kw>
            <kw>OSI</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tuba</wg_acronym>
        <doi>10.17487/RFC1561</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Australia</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1562</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>email</kw>
            <kw>mail</kw>
            <kw>richtext</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1563</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>x.500</kw>
            <kw>Directory</kw>
            <kw>Service</kw>
            <kw>Agent</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1564</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2248</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC1565</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC1566</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>X500-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2605</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC1567</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Beeper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1645</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1568</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Beeper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1703</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1569</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1570</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1408</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1571</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TOPT-ENVIR</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>telnet</wg_acronym>
        <doi>10.17487/RFC1572</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC1573</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Echo</kw>
            <kw>Traceroute</kw>
            <kw>Routing Table</kw>
            <kw>CLNP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1139</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>noop</wg_acronym>
        <doi>10.17487/RFC1574</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ISO-TS-ECHO</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1139</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>noop</wg_acronym>
        <doi>10.17487/RFC1575</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Telnet Option Terminal Type EOR Binary</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC1576</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Asynchronous</kw>
            <kw>Transmission</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2225</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipatm</wg_acronym>
        <doi>10.17487/RFC1577</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>K12</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1941</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>isn</wg_acronym>
        <doi>10.17487/RFC1578</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>PORT</kw>
            <kw>PASV</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1579</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>107</page-count>
        <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><p>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]</p></abstract>
        <is-also>
            <doc-id>FYI0023</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1580</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1581</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>RIP-DC</kw>
            <kw>routing</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1582</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>216</page-count>
        <keywords>
            <kw>equal-cost</kw>
            <kw>multipath</kw>
            <kw>link state</kw>
            <kw>LSA</kw>
        </keywords>
        <abstract><p>This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1583</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>102</page-count>
        <keywords>
            <kw>OSPF-Multi</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract><p>This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1584</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1585</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>FR</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1586</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3101</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1587</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>X-500 directory</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1588</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Time</kw>
            <kw>NTP</kw>
            <kw>Clock</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1589</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>email</kw>
            <kw>multimedia</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1590</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Policy</kw>
            <kw>Top-Level</kw>
            <kw>TLD</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1591</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>SNMP-DPI</kw>
            <kw>SNMP</kw>
            <kw>DPT</kw>
            <kw>IBM</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1228</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1592</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>120</page-count>
        <keywords>
            <kw>IBM</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1593</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>documentation</kw>
            <kw>help</kw>
            <kw>information</kw>
            <kw>FAQ</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>uswg</wg_acronym>
        <doi>10.17487/RFC1594</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC1595</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>frnetmib</wg_acronym>
        <doi>10.17487/RFC1596</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Network</kw>
            <kw>Number</kw>
            <kw>Local</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1918</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1597</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>PPP-X25</kw>
            <kw>point</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1598</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1599</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1540</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1610</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1600</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ISOC</kw>
            <kw>Internet Society</kw>
            <kw>IETF</kw>
            <kw>IRTF</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1601</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1602</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>WG</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC1603</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>FR-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>Network</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1604</doi>
    </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>1</day>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Humor</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1605</doi>
    </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>1</day>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Humor</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1606</errata-url>
        <doi>10.17487/RFC1606</doi>
    </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>1</day>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>V. Cerf</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1607</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>X500-DIR</kw>
            <kw>Data</kw>
            <kw>Structure</kw>
            <kw>Schemo</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1608</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>X500-CHART</kw>
            <kw>Data</kw>
            <kw>Structure</kw>
            <kw>Schemo</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1609</errata-url>
        <doi>10.17487/RFC1609</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1600</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1720</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1610</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <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><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dns</wg_acronym>
        <doi>10.17487/RFC1611</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <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><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dns</wg_acronym>
        <doi>10.17487/RFC1612</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1613</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>imm</wg_acronym>
        <doi>10.17487/RFC1614</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1615</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Romaguera</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1616</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
            <kw>White Pages</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1384</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1617</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PPP-ISDN</kw>
            <kw>Point</kw>
            <kw>Integrated Services Digital Network</kw>
        </keywords>
        <abstract><p>This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1618</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>PPP-SONET</kw>
            <kw>Point</kw>
            <kw>Synchronous Optical Network Digital Heirarchy</kw>
        </keywords>
        <abstract><p>This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2615</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1619</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Public</kw>
            <kw>data</kw>
            <kw>networks</kw>
            <kw>ARP</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1620</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pip</wg_acronym>
        <doi>10.17487/RFC1621</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pip</wg_acronym>
        <doi>10.17487/RFC1622</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1398</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1643</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC1623</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1141</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1624</errata-url>
        <doi>10.17487/RFC1624</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Wide</kw>
            <kw>Area</kw>
            <kw>Information</kw>
            <kw>Servers</kw>
            <kw>Library</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>iiir</wg_acronym>
        <doi>10.17487/RFC1625</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2225</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipatm</wg_acronym>
        <doi>10.17487/RFC1626</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Network</kw>
            <kw>Number</kw>
            <kw>Local</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1918</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1627</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>UPS-MIB</kw>
            <kw>Uninterruptible</kw>
            <kw>Power</kw>
            <kw>Supply</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>upsmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1628</errata-url>
        <doi>10.17487/RFC1628</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>OSI-NSAP</kw>
            <kw>CLNP</kw>
            <kw>Address</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1237</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>osinsap</wg_acronym>
        <doi>10.17487/RFC1629</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>WWW</kw>
            <kw>World Wide Web</kw>
            <kw>URI</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1630</errata-url>
        <doi>10.17487/RFC1630</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3022</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1632</doc-id>
        <title>A Revised Catalog of Available X.500 Implementations</title>
        <author>
            <name>A. Getchell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sataluri</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>Directory</kw>
            <kw>White</kw>
            <kw>Pages</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC1632</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>real time</kw>
            <kw>Multi-media</kw>
            <kw>reservations</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1633</errata-url>
        <doi>10.17487/RFC1633</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>wide</kw>
            <kw>area</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1551</doc-id>
            <doc-id>RFC1362</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1634</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>File</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0024</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>iafa</wg_acronym>
        <doi>10.17487/RFC1635</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1636</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>ISO</kw>
            <kw>OSI</kw>
            <kw>Address</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1637</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>PPP-BCP</kw>
            <kw>Point to Point</kw>
        </keywords>
        <abstract><p>This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1638</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>FOOBAR</kw>
            <kw>File</kw>
            <kw>Transfer</kw>
            <kw>Port</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1545</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1639</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IETF</kw>
            <kw>IESG</kw>
            <kw>IAB</kw>
            <kw>ISOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1640</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>This document specifies the usage of Unicode within MIME.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1641</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>character</kw>
            <kw>Set</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2152</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1642</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ETHER-MIB</kw>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>Ethernet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1623</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3638</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1643</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>T/TCP</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1379</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1644</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Beeper</kw>
            <kw>SNPP</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1645</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Telnet</kw>
            <kw>Option</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC1646</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Telnet</kw>
            <kw>Option</kw>
        </keywords>
        <abstract><p>This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2355</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC1647</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>x400ops</wg_acronym>
        <doi>10.17487/RFC1648</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Mail</kw>
            <kw>Global</kw>
            <kw>Open</kw>
            <kw>Message</kw>
            <kw>Handling</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>x400ops</wg_acronym>
        <doi>10.17487/RFC1649</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>802.3</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2358</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC1650</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Mail</kw>
            <kw>Simple</kw>
            <kw>Transfer</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1651</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>Mail</kw>
            <kw>Simple</kw>
            <kw>Transfer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1426</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6152</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1652</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Mail</kw>
            <kw>Simple</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1654</doc-id>
        <title>A Border Gateway Protocol 4 (BGP-4)</title>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1771</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1654</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Gross</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>BGP-4</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1655</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1773</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1656</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>BGP-4-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4273</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1657</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1316</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>charmib</wg_acronym>
        <doi>10.17487/RFC1658</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1317</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>charmib</wg_acronym>
        <doi>10.17487/RFC1659</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1318</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>charmib</wg_acronym>
        <doi>10.17487/RFC1660</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>Specification</kw>
            <kw>Standard</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract><p>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]</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1661</errata-url>
        <doi>10.17487/RFC1661</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <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><p>This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1549</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0051</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1662</errata-url>
        <doi>10.17487/RFC1662</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>PPP-TRANS</kw>
            <kw>Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1663</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>X.400</kw>
            <kw>Email</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2163</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>x400ops</wg_acronym>
        <doi>10.17487/RFC1664</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Kostick</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Shih</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1666</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC1665</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Kostick</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Shih</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <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><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1665</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1666</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1667</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1668</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>"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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1669</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1670</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1671</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1672</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1673</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1674</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1675</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1676</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1677</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1678</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1679</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1680</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1681</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Unix</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1682</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1683</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Directory</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1684</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>EMail</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RTR0012</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1685</errata-url>
        <doi>10.17487/RFC1685</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1686</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1687</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1688</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>226</page-count>
        <keywords>
            <kw>NIR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0025</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>nir</wg_acronym>
        <doi>10.17487/RFC1689</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>charter</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1690</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1691</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TMUX</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>One of the problems with the use of terminal servers is the large number of small packets they can generate.  Frequently, most of these packets are destined for only one or two hosts.  TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1692</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>TCP-POS</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6247</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1693</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Tesink</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>SIP-MIB</kw>
            <kw>Standard</kw>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Switched</kw>
            <kw>Multimegabit</kw>
            <kw>Data</kw>
            <kw>Service</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SMDS</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1304</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC1694</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Tesink</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>ATM-MIB</kw>
            <kw>MIB</kw>
            <kw>Management,Information,Base,Asychronous,Transmission,Mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2515</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC1695</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>MODEM-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>modemmgt</wg_acronym>
        <doi>10.17487/RFC1696</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>RDBMS-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>rdbmsmib</wg_acronym>
        <doi>10.17487/RFC1697</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Protocol</kw>
            <kw>Headers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>thinosi</wg_acronym>
        <doi>10.17487/RFC1698</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1699</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>230</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
            <kw>parameters</kw>
            <kw>registered</kw>
            <kw>allocated</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1340</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3232</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1700</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>GRE</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1701</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>GRE-IPv4</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1702</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>RADIO-PAGE</kw>
            <kw>Beepers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1569</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1703</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Energyption</kw>
            <kw>Policy</kw>
            <kw>Guidelines</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1704</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1705</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1637</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9121</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1706</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>IPv7</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1707</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1708</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>school</kw>
            <kw>network</kw>
            <kw>education</kw>
            <kw>connection</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0026</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>isn</wg_acronym>
        <doi>10.17487/RFC1709</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SIPP</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>sipp</wg_acronym>
        <doi>10.17487/RFC1710</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Email</kw>
            <kw>Electronic</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1711</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS-ENCODE</kw>
            <kw>Domain</kw>
            <kw>Names</kw>
            <kw>System</kw>
            <kw>GPOS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1712</errata-url>
        <doi>10.17487/RFC1712</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0027</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1713</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Pages</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2167</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1714</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC3194</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1715</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>192</page-count>
        <keywords>
            <kw>Gateway</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1812</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rreq</wg_acronym>
        <doi>10.17487/RFC1716</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Point</kw>
        </keywords>
        <abstract><p>This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1990</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1717</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
            <kw>Meeting</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1718</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1719</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1610</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1780</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1720</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1387</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC1721</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>RIP2-APP</kw>
            <kw>RIP-2</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <is-also>
            <doc-id>STD0057</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC1722</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1388</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2453</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1058</doc-id>
        </updates>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC1723</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RIP2-MIB</kw>
            <kw>RIP-2</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1389</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1724</errata-url>
        <doi>10.17487/RFC1724</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>POP</kw>
            <kw>Email</kw>
            <kw>Electronic</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1460</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1939</doc-id>
        </obsoleted-by>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1725</errata-url>
        <doi>10.17487/RFC1725</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1726</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Names</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>iiir</wg_acronym>
        <doi>10.17487/RFC1727</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Names</kw>
            <kw>Location</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>iiir</wg_acronym>
        <doi>10.17487/RFC1728</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Basic</kw>
            <kw>Endcoding</kw>
            <kw>Rules</kw>
            <kw>ASN1</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>iiir</wg_acronym>
        <doi>10.17487/RFC1729</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>IMAP4</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imap</wg_acronym>
        <doi>10.17487/RFC1730</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IMAP4-AUTH</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imap</wg_acronym>
        <doi>10.17487/RFC1731</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imap</wg_acronym>
        <doi>10.17487/RFC1732</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imap</wg_acronym>
        <doi>10.17487/RFC1733</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>POP3-AUTH</kw>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5034</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1734</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rolc</wg_acronym>
        <doi>10.17487/RFC1735</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>URL</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1736</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1737</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>URL</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4248</doc-id>
            <doc-id>RFC4266</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1808</doc-id>
            <doc-id>RFC2368</doc-id>
            <doc-id>RFC2396</doc-id>
            <doc-id>RFC3986</doc-id>
            <doc-id>RFC6196</doc-id>
            <doc-id>RFC6270</doc-id>
            <doc-id>RFC8089</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1738</errata-url>
        <doi>10.17487/RFC1738</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2151</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1739</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>MacMIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1740</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>BINHEX</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1741</errata-url>
        <doi>10.17487/RFC1741</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>AT-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1243</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>appleip</wg_acronym>
        <doi>10.17487/RFC1742</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP,</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC1743</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1744</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1745</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>isn</wg_acronym>
        <doi>10.17487/RFC1746</doi>
    </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>
        </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>SDLCSMIv2</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snadlc</wg_acronym>
        <doi>10.17487/RFC1747</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>802.5-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1748</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>802.5-SSR</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC1748</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC1749</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Random</kw>
            <kw>Numbers</kw>
            <kw>Seed</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4086</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1750</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Password</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1751</errata-url>
        <doi>10.17487/RFC1751</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>IPNG</kw>
            <kw>IPng</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1752</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1753</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Asynchromous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1754</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>ATM</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract><p>This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipatm</wg_acronym>
        <doi>10.17487/RFC1755</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RWP</kw>
            <kw>Application</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1756</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>MIB</kw>
            <kw>RMON</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC1757</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1417</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1758</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>113</page-count>
        <keywords>
            <kw>Print-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3805</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>printmib</wg_acronym>
        <doi>10.17487/RFC1759</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1760</errata-url>
        <doi>10.17487/RFC1760</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SNOOP</kw>
            <kw>Measurement</kw>
            <kw>debugging</kw>
            <kw>collecting</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1761</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PPP-DNCP</kw>
            <kw>Point</kw>
            <kw>Digital</kw>
            <kw>Equipment</kw>
            <kw>Corporation</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1376</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1762</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BVCP</kw>
            <kw>Point</kw>
        </keywords>
        <abstract><p>This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1763</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>XNSCP</kw>
            <kw>Point</kw>
            <kw>Xerox</kw>
            <kw>Network</kw>
            <kw>Internetwork</kw>
            <kw>Datagram</kw>
            <kw>Service</kw>
        </keywords>
        <abstract><p>This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1764</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>OSPF-OVFL</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1765</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Lang-Tag</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1766</errata-url>
        <doi>10.17487/RFC1766</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>edi</wg_acronym>
        <doi>10.17487/RFC1767</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>CLNP-MULT</kw>
            <kw>ISO</kw>
            <kw>OSI</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tuba</wg_acronym>
        <doi>10.17487/RFC1768</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Clocks</kw>
            <kw>Synchronization</kw>
            <kw>NTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1361</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2030</doc-id>
            <doc-id>RFC4330</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1769</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SDMD</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6814</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1770</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>BGP-4</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1654</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4271</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1771</errata-url>
        <doi>10.17487/RFC1771</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>BGP-4-APP</kw>
            <kw>BGP-4</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1655</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bgp</wg_acronym>
        <doi>10.17487/RFC1772</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>BGP-4</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1656</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1773</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1774</errata-url>
        <doi>10.17487/RFC1774</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>access</kw>
            <kw>full</kw>
            <kw>Client</kw>
            <kw>Mediated</kw>
            <kw>Messaging</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1775</doi>
    </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>1</day>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1776</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>DAP</kw>
            <kw>interactive</kw>
            <kw>access</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC1777</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>X.500</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory protocol</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC1778</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>STR-REP</kw>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC1779</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1720</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1800</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1780</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>OSI-Dir</kw>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC1781</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tftpexts</wg_acronym>
        <doi>10.17487/RFC1782</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract><p>This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tftpexts</wg_acronym>
        <doi>10.17487/RFC1783</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tftpexts</wg_acronym>
        <doi>10.17487/RFC1784</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tftpexts</wg_acronym>
        <doi>10.17487/RFC1785</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1786</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Architechure Board</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1787</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6918</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1788</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1789</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>ISOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1790</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Transmission Control Protocol</kw>
            <kw>User Datagram</kw>
            <kw>Maximum Transmission Unit</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1791</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1792</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>OSPF-DC</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract><p>This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC3883</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1793</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dns</wg_acronym>
        <doi>10.17487/RFC1794</doi>
    </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>
        </author>
        <author>
            <name>A. Bartky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>IBM</kw>
            <kw>SNA</kw>
            <kw>DLS</kw>
            <kw>SSP</kw>
            <kw>NetBIos</kw>
            <kw>APPN</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1434</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1795</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1796</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>Address</kw>
            <kw>39</kw>
            <kw>Number</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1797</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>CLDAP</kw>
            <kw>CLDAP</kw>
            <kw>Presentation</kw>
            <kw>Address</kw>
            <kw>Application</kw>
            <kw>Entity</kw>
            <kw>Title</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3352</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>osids</wg_acronym>
        <doi>10.17487/RFC1798</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1799</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1780</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1880</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1800</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <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><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhsds</wg_acronym>
        <doi>10.17487/RFC1801</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Mail</kw>
            <kw>EMail</kw>
            <kw>Message</kw>
            <kw>Handling</kw>
            <kw>System</kw>
            <kw>MHS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhsds</wg_acronym>
        <doi>10.17487/RFC1802</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Pages</kw>
            <kw>DSA</kw>
            <kw>Directory</kw>
            <kw>User</kw>
            <kw>Agent</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC1803</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC1804</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Betsi</kw>
            <kw>Security</kw>
            <kw>Cryptography</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1805</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>EMail</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2183</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1806</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>library</kw>
            <kw>technical reports</kw>
            <kw>email services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1357</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1807</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>URL</kw>
            <kw>URL</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1808</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1809</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Message</kw>
            <kw>Digest</kw>
            <kw>Algorithm</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1810</errata-url>
        <doi>10.17487/RFC1810</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>GOV</kw>
            <kw>FNC</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1816</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1811</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>175</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract><p>This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1716</doc-id>
            <doc-id>RFC1009</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2644</doc-id>
            <doc-id>RFC6633</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rreq</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1812</errata-url>
        <doi>10.17487/RFC1812</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>126</page-count>
        <keywords>
            <kw>NFSV3</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <see-also>
            <doc-id>RFC1094</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1813</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Registries</kw>
            <kw>Protocol</kw>
            <kw>Private</kw>
            <kw>Network</kw>
            <kw>Numbers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1814</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Japanese</kw>
            <kw>Latin</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1815</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>GOV</kw>
            <kw>FNC</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1816</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>Classless</kw>
            <kw>Inter</kw>
            <kw>Domain</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1817</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>BCP</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1818</errata-url>
        <doi>10.17487/RFC1818</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <keywords>
            <kw>ST2</kw>
        </keywords>
        <abstract><p>This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <obsoletes>
            <doc-id>RFC1190</doc-id>
            <doc-id>IEN119</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>st2</wg_acronym>
        <doi>10.17487/RFC1819</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Media</kw>
            <kw>Types</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1844</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1820</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1821</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Key</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>IKMP</kw>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1822</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>API</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1823</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>TESS</kw>
            <kw>public</kw>
            <kw>keys</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1824</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>IP-layer</kw>
            <kw>ipsec</kw>
        </keywords>
        <abstract><p>This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2401</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC1825</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2402</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC1826</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ESP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>ipsec</kw>
        </keywords>
        <abstract><p>This document describes the IP Encapsulating Security Payload (ESP).  ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2406</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC1827</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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>MD5</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC1828</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC1829</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Multipurpose</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3030</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <doi>10.17487/RFC1830</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RPC</kw>
            <kw>ONC</kw>
            <kw>Open</kw>
            <kw>Network</kw>
            <kw>Computing</kw>
        </keywords>
        <abstract><p>This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5531</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>oncrpc</wg_acronym>
        <doi>10.17487/RFC1831</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>XDR</kw>
            <kw>RPC</kw>
            <kw>ONC</kw>
            <kw>Open</kw>
            <kw>Network</kw>
            <kw>Computing</kw>
        </keywords>
        <abstract><p>This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4506</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>oncrpc</wg_acronym>
        <doi>10.17487/RFC1832</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ONC</kw>
            <kw>Open</kw>
            <kw>Network</kw>
            <kw>Computing</kw>
        </keywords>
        <abstract><p>This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC5665</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>oncrpc</wg_acronym>
        <doi>10.17487/RFC1833</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>wnils</wg_acronym>
        <doi>10.17487/RFC1834</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <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><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>wnils</wg_acronym>
        <doi>10.17487/RFC1835</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>message</kw>
            <kw>handling</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2294</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhsds</wg_acronym>
        <doi>10.17487/RFC1836</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>message</kw>
            <kw>handling</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2293</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhsds</wg_acronym>
        <doi>10.17487/RFC1837</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>message</kw>
            <kw>handling</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2164</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhsds</wg_acronym>
        <doi>10.17487/RFC1838</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1841</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>HZ-GB-2312</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1842</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>GB2312-80</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1843</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Media</kw>
            <kw>Types</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1820</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <doi>10.17487/RFC1844</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>transaction</kw>
        </keywords>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <doi>10.17487/RFC1845</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
        </keywords>
        <updated-by>
            <doc-id>RFC7504</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <doi>10.17487/RFC1846</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MIME-Encyp</kw>
            <kw>mail</kw>
            <kw>multipurpose</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <doi>10.17487/RFC1847</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>MIME-Sec</kw>
            <kw>mail</kw>
            <kw>multipurpose</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pem</wg_acronym>
        <doi>10.17487/RFC1848</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1849</doc-id>
        <title>"Son of 1036": News Article Format and Transmission</title>
        <author>
            <name>H. Spencer</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>106</page-count>
        <keywords>
            <kw>netnews</kw>
            <kw>usenet</kw>
            <kw>rfc 1036</kw>
            <kw>usefor</kw>
            <kw>historic</kw>
        </keywords>
        <abstract><p>By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews.</p><p> It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-spencer-usefor-son-of-1036-01</draft>
        <obsoleted-by>
            <doc-id>RFC5536</doc-id>
            <doc-id>RFC5537</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1849</doi>
    </rfc-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <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><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1253</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4750</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC1850</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ESP3DES</kw>
            <kw>encryption encapsulating security payload cipher block chaining</kw>
        </keywords>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1851</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1852</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet protocol payload encapsulation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1853</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2197</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <doi>10.17487/RFC1854</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>Etiquette</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0028</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>run</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1855</errata-url>
        <doi>10.17487/RFC1855</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>tools</kw>
            <kw>performance</kw>
            <kw>utilization</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>opstat</wg_acronym>
        <doi>10.17487/RFC1856</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>metrics</kw>
            <kw>measurements</kw>
            <kw>polling periods</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1404</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>opstat</wg_acronym>
        <doi>10.17487/RFC1857</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC3128</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1858</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>International</kw>
            <kw>Standard</kw>
            <kw>Organizatio</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1859</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>values</kw>
            <kw>IPv4</kw>
            <kw>subnets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC1878</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1860</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SNPP</kw>
            <kw>SNPP</kw>
            <kw>wireless</kw>
            <kw>paging</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1645</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1861</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1862</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>BGP-IDRP</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>inter-domain</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4223</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1863</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>CON-MD5</kw>
            <kw>MIME</kw>
            <kw>EMail</kw>
            <kw>Integrity</kw>
            <kw>MIC</kw>
            <kw>Digest</kw>
        </keywords>
        <abstract><p>This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1544</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1864</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>FAQ</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>edi</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1865</errata-url>
        <doi>10.17487/RFC1865</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>HTML</kw>
            <kw>SGML</kw>
            <kw>Standard</kw>
            <kw>Generalized</kw>
            <kw>Language</kw>
            <kw>WWW</kw>
            <kw>World Wide Web</kw>
        </keywords>
        <abstract><p>This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>html</wg_acronym>
        <doi>10.17487/RFC1866</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>html</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1867</errata-url>
        <doi>10.17487/RFC1867</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>UNARP</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Protocol</kw>
            <kw>delete</kw>
            <kw>entry</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1868</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ESMTP</kw>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1869</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SMTP-SIZE</kw>
            <kw>Simple Mail Transfer Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1653</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0010</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>smtpext</wg_acronym>
        <doi>10.17487/RFC1870</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>BCP</kw>
            <kw>WG</kw>
            <kw>escape</kw>
            <kw>clause</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2026</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1602</doc-id>
            <doc-id>RFC1603</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1871</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2112</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mimesgml</wg_acronym>
        <doi>10.17487/RFC1872</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1873</doc-id>
        <title>Message/External-Body Content-ID Access Type</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <author>
            <name>J. Clark</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>CONT-MT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mimesgml</wg_acronym>
        <doi>10.17487/RFC1873</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SGML-MT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>This document proposes new media sub-types of Text/SGML and Application/SGML.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mimesgml</wg_acronym>
        <doi>10.17487/RFC1874</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Policy</kw>
            <kw>Certification</kw>
            <kw>Authority</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1875</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DNS-LOC</kw>
            <kw>DNS</kw>
            <kw>Resource</kw>
            <kw>Record</kw>
            <kw>(RR)</kw>
            <kw>LOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1876</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1877</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>values</kw>
            <kw>IPv4</kw>
            <kw>subnets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1860</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1878</errata-url>
        <doi>10.17487/RFC1878</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Registry</kw>
            <kw>Operations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1879</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1800</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1920</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1880</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>Internet</kw>
            <kw>Assigned</kw>
            <kw>Numbers</kw>
            <kw>Authority</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1881</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1882</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2460</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1883</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1884</doc-id>
        <title>IP Version 6 Addressing Architecture</title>
        <author>
            <name>R. Hinden</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Deering</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>IPV6-Addr</kw>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2373</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1884</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <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><p>This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2463</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1885</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1887</doc-id>
        <title>An Architecture for IPv6 Unicast Address Allocation</title>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng,</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1887</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Open</kw>
            <kw>Systems</kw>
            <kw>Interconnection</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4048</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4548</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1888</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>RTCP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3550</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC1889</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RTP-AV</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>conference</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3551</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC1890</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>SMTP-DSN</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3461</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>notary</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1891</errata-url>
        <doi>10.17487/RFC1891</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>MIME-RPT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3462</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>notary</wg_acronym>
        <doi>10.17487/RFC1892</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>EMS-CODE</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3463</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>notary</wg_acronym>
        <doi>10.17487/RFC1893</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>DSN</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Content</kw>
            <kw>Type</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>notary</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1894</errata-url>
        <doi>10.17487/RFC1894</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MIL-STD-1840</kw>
            <kw>MIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1895</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1523</doc-id>
            <doc-id>RFC1563</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1896</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>prototype</kw>
            <kw>software</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2471</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1897</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>general</kw>
            <kw>payments</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1898</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1899</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>network</kw>
            <kw>number</kw>
            <kw>addressing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1900</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SNMPV2CB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1901</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1902</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1903</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1904</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>OPS-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1905</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>TRANS-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1906</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>SNMPv2-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1907</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>COEX-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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). [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC1908</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SNMPV2AI</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1909</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>SNMPV2SM</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1910</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <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><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1911</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1537</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1912</errata-url>
        <doi>10.17487/RFC1912</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>WHOIS++A</kw>
            <kw>Bunyip Information Systems</kw>
            <kw>Inc.</kw>
            <kw>MCNC Center for Communications</kw>
        </keywords>
        <abstract><p>The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>wnils</wg_acronym>
        <doi>10.17487/RFC1913</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>WHOIS++M</kw>
            <kw>distributed</kw>
            <kw>databases</kw>
            <kw>directory</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>wnils</wg_acronym>
        <doi>10.17487/RFC1914</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Point</kw>
            <kw>to</kw>
            <kw>Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0003</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1915</errata-url>
        <doi>10.17487/RFC1915</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>tools</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>pier</wg_acronym>
        <doi>10.17487/RFC1916</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>address</kw>
            <kw>space</kw>
            <kw>Internet</kw>
            <kw>Assigned</kw>
            <kw>Numbers</kw>
            <kw>Authority</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0004</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>cidrd</wg_acronym>
        <doi>10.17487/RFC1917</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>TCP/IP</kw>
            <kw>network</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1627</doc-id>
            <doc-id>RFC1597</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6761</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0005</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>cidrd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1918</errata-url>
        <doi>10.17487/RFC1918</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>firewalls</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1919</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1880</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2000</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1920</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1921</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>transport</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>telnet</kw>
            <kw>WWW</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1922</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rip</wg_acronym>
        <doi>10.17487/RFC1923</doi>
    </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>1</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>encoding</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1924</doi>
    </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>1</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>fundamentals</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1925</errata-url>
        <doi>10.17487/RFC1925</doi>
    </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>1</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>Acoustical</kw>
            <kw>Transmission</kw>
            <kw>Media (ATM)</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC1926</doi>
    </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>1</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>media-type</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1927</errata-url>
        <doi>10.17487/RFC1927</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SOCKSV5</kw>
            <kw>firewalls</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>aft</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1928</errata-url>
        <doi>10.17487/RFC1928</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>AUTH-SOCKS</kw>
            <kw>firewalls</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>aft</wg_acronym>
        <doi>10.17487/RFC1929</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC6996</doc-id>
            <doc-id>RFC7300</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0006</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1930</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Reverse</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1931</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>end-to-end</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipatm</wg_acronym>
        <doi>10.17487/RFC1932</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>TRANS-IPV6</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract><p>This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2893</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC1933</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>PPP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1934</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>information</kw>
            <kw>tutorial</kw>
        </keywords>
        <abstract><p>This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1935</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>PLD</kw>
            <kw>code</kw>
            <kw>UDP</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1936</errata-url>
        <doi>10.17487/RFC1936</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>subnet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rolc</wg_acronym>
        <doi>10.17487/RFC1937</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>OTP</kw>
            <kw>authentication</kw>
            <kw>S/KEY</kw>
        </keywords>
        <abstract><p>This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2289</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>otp</wg_acronym>
        <doi>10.17487/RFC1938</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>POP3</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1725</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1957</doc-id>
            <doc-id>RFC2449</doc-id>
            <doc-id>RFC6186</doc-id>
            <doc-id>RFC8314</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0053</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1939</errata-url>
        <doi>10.17487/RFC1939</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>SDRP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sdr</wg_acronym>
        <doi>10.17487/RFC1940</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>FAQ</kw>
            <kw>Internet</kw>
            <kw>Education</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>isn</wg_acronym>
        <doi>10.17487/RFC1941</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>HTML-TBL</kw>
            <kw>HyperText</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>SGML</kw>
        </keywords>
        <abstract><p>This specification extends HTML to support a wide variety of tables.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>html</wg_acronym>
        <doi>10.17487/RFC1942</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>White</kw>
            <kw>Pages</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC1943</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>testing</kw>
            <kw>performance</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2544</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC1944</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>HTTP-1.0</kw>
            <kw>HTTP</kw>
            <kw>World-Wide</kw>
            <kw>Web</kw>
            <kw>application</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1945</errata-url>
        <doi>10.17487/RFC1945</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>integrated</kw>
            <kw>services</kw>
            <kw>ATM</kw>
            <kw>Quality</kw>
            <kw>of</kw>
            <kw>Service</kw>
            <kw>QoS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1946</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>character</kw>
            <kw>set</kw>
            <kw>ISO</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1947</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>crypgraphic</kw>
            <kw>authentication</kw>
            <kw>spoofing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6528</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1948</errata-url>
        <doi>10.17487/RFC1948</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SMKD</kw>
            <kw>MBONE</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This memo provides a scalable solution to the multicast key distribution problem.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC1949</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ZLIB</kw>
            <kw>compressed</kw>
            <kw>data</kw>
            <kw>format</kw>
            <kw>checksum</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1950</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>DEFLATE</kw>
            <kw>compressed</kw>
            <kw>data</kw>
            <kw>format</kw>
            <kw>coding</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1951</errata-url>
        <doi>10.17487/RFC1951</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>GZIP</kw>
            <kw>compressed</kw>
            <kw>data</kw>
            <kw>format</kw>
            <kw>redundancy</kw>
            <kw>check</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1952</errata-url>
        <doi>10.17487/RFC1952</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IFMP</kw>
            <kw>IP</kw>
            <kw>flow</kw>
            <kw>routing</kw>
            <kw>information</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1953</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>datagrams</kw>
            <kw>IFMP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1954</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IPNG</kw>
            <kw>addressing</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1955</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>DoD</kw>
            <kw>Department</kw>
            <kw>of</kw>
            <kw>Defense</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1956</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</p></abstract>
        <updates>
            <doc-id>RFC1939</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1957</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC3439</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC1958</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2255</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1959</errata-url>
        <doi>10.17487/RFC1959</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>LDAP-STR</kw>
            <kw>Lightweight</kw>
            <kw>Directory</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC1960</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>aft</wg_acronym>
        <doi>10.17487/RFC1961</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>PPP-CCP</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>data</kw>
            <kw>links</kw>
        </keywords>
        <abstract><p>This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC2153</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1962</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1963</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <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><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC4121</doc-id>
            <doc-id>RFC6649</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1964</errata-url>
        <doi>10.17487/RFC1964</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>BGP-ASC</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3065</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1965</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>BGP-RR</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4456</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2796</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1966</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Compression</kw>
            <kw>Control</kw>
            <kw>CCP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1967</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PPP-ECP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1968</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>encapsulated</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2419</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1969</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2461</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1970</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <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><p>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2462</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>addrconf</wg_acronym>
        <doi>10.17487/RFC1971</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IPV6-ETHER</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>transmission</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2464</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC1972</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP-FRAME</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>encapsulated</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1973</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>PPP-STAC</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Compression</kw>
            <kw>Control</kw>
            <kw>CCP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1974</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>PPP-MAG</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>MVRCA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1975</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP-DCE</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>LCP</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1976</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>PPP-BSD</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Unix</kw>
            <kw>Compress</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1977</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>PPP-PRED</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1978</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP-DEFL</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Compression</kw>
            <kw>Control</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1979</errata-url>
        <doi>10.17487/RFC1979</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>HyperText</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>Uniform</kw>
            <kw>Identifier</kw>
            <kw>URI</kw>
        </keywords>
        <abstract><p>The markup language known as "HTML/2.0" provides for image maps.  Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs).  The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers.  This document specifies an extension to the HTML language, referred to as "Client- Side Image Maps," which resolves these limitations.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1980</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MTU-IPV6</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC8201</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1981</errata-url>
        <doi>10.17487/RFC1981</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SNA</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <doi>10.17487/RFC1982</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>basic</kw>
            <kw>terms</kw>
            <kw>acronyms</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>userglos</wg_acronym>
        <doi>10.17487/RFC1983</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>security</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0200</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1984</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>SMTP-ETRN</kw>
            <kw>Simple</kw>
            <kw>ETRN</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc1985</errata-url>
        <doi>10.17487/RFC1985</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>ETFTP</kw>
            <kw>TFTP</kw>
            <kw>NETBLT</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1986</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>GSMP</kw>
            <kw>ATM</kw>
            <kw>switch</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC2297</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1987</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>HP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1988</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PPP-LINK</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1333</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1989</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>PPP-MP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>datagrams</kw>
        </keywords>
        <abstract><p>This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1717</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1990</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4880</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1991</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>scalable</kw>
            <kw>internetwork</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nimrod</wg_acronym>
        <doi>10.17487/RFC1992</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1993</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PPP-CHAP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC1994</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNS-IZT</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>IXFR</kw>
        </keywords>
        <abstract><p>This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]</p></abstract>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9103</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1995</errata-url>
        <doi>10.17487/RFC1995</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS-NOTIFY</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <doi>10.17487/RFC1996</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BGP-COMM</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC7606</doc-id>
            <doc-id>RFC8642</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc1997</errata-url>
        <doi>10.17487/RFC1997</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC1998</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC1999</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1920</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2200</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2000</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TCPSLOWSRT</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2581</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2001</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC2002</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IPENCAPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC3168</doc-id>
            <doc-id>RFC6864</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2003</errata-url>
        <doi>10.17487/RFC2003</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MINI-IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2004</errata-url>
        <doi>10.17487/RFC2004</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC2005</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2006</errata-url>
        <doi>10.17487/RFC2006</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>TRAINMAT</kw>
            <kw>IETF</kw>
            <kw>TERENA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0029</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>trainmat</wg_acronym>
        <doi>10.17487/RFC2007</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0007</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>cidrd</wg_acronym>
        <doi>10.17487/RFC2008</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>GPS-AR</kw>
            <kw>domain</kw>
            <kw>names</kw>
            <kw>geographic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2009</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>host</kw>
            <kw>hardware</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2870</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2010</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4293</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC2011</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC2012</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4113</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>snmpv2</wg_acronym>
        <doi>10.17487/RFC2013</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Research</kw>
            <kw>Task</kw>
            <kw>Force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0008</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2014</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MIME-PGP</kw>
            <kw>Authentication</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC3156</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2015</errata-url>
        <doi>10.17487/RFC2015</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>URAS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2016</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <doi>10.17487/RFC2017</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2018</doc-id>
        <title>TCP Selective Acknowledgment 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TCP-ACK</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>SACK</kw>
        </keywords>
        <abstract><p>This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1072</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcplw</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2018</errata-url>
        <doi>10.17487/RFC2018</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2467</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2019</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>802.12-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>vgmib</wg_acronym>
        <doi>10.17487/RFC2020</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>130</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>RMON</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4502</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2021</errata-url>
        <doi>10.17487/RFC2021</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>MULTI-UNI</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipatm</wg_acronym>
        <doi>10.17487/RFC2022</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPV6-PPP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Point</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2472</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2023</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>DLSW-MIB</kw>
            <kw>MIB</kw>
            <kw>DLSW</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>dlswmib</wg_acronym>
        <doi>10.17487/RFC2024</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>SPKM</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2025</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Protocols</kw>
            <kw>copyrights</kw>
            <kw>intellectual</kw>
            <kw>property</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1602</doc-id>
            <doc-id>RFC1871</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3667</doc-id>
            <doc-id>RFC3668</doc-id>
            <doc-id>RFC3932</doc-id>
            <doc-id>RFC3978</doc-id>
            <doc-id>RFC3979</doc-id>
            <doc-id>RFC5378</doc-id>
            <doc-id>RFC5657</doc-id>
            <doc-id>RFC5742</doc-id>
            <doc-id>RFC6410</doc-id>
            <doc-id>RFC7100</doc-id>
            <doc-id>RFC7127</doc-id>
            <doc-id>RFC7475</doc-id>
            <doc-id>RFC8179</doc-id>
            <doc-id>RFC8789</doc-id>
            <doc-id>RFC9282</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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poised95</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2026</errata-url>
        <doi>10.17487/RFC2026</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>Engineering</kw>
            <kw>Steering</kw>
            <kw>Group</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2282</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poised95</wg_acronym>
        <doi>10.17487/RFC2027</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC9281</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3668</doc-id>
            <doc-id>RFC3979</doc-id>
            <doc-id>RFC8717</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poised95</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2028</errata-url>
        <doi>10.17487/RFC2028</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>RTP-CELLB</kw>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2029</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>SNTP</kw>
            <kw>time</kw>
            <kw>computer</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1769</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4330</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2030</errata-url>
        <doi>10.17487/RFC2030</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Society</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC8712</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poised95</wg_acronym>
        <doi>10.17487/RFC2031</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RTP-H.261</kw>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4587</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2032</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>LMTP</kw>
            <kw>SMTP</kw>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2033</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SMTP-ENH</kw>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2034</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2435</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2035</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Assigned</kw>
            <kw>Numbers</kw>
            <kw>Authority</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>cidrd</wg_acronym>
        <doi>10.17487/RFC2036</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>ENTITY-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2737</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>entmib</wg_acronym>
        <doi>10.17487/RFC2037</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2250</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2038</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2039</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>RC5</kw>
            <kw>Cipher</kw>
            <kw>Block</kw>
            <kw>Chaining</kw>
            <kw>CBC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2040</errata-url>
        <doi>10.17487/RFC2040</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2041</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2042</errata-url>
        <doi>10.17487/RFC2042</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PPP-SNACP</kw>
            <kw>Point-to-point</kw>
            <kw>protocol</kw>
            <kw>systems</kw>
            <kw>network</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2043</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>UCS</kw>
            <kw>Transformation</kw>
            <kw>Format</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2279</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2044</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>media</kw>
            <kw>types</kw>
            <kw>headers</kw>
        </keywords>
        <abstract><p>This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]</p></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>
            <doc-id>RFC5335</doc-id>
            <doc-id>RFC6532</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2045</errata-url>
        <doi>10.17487/RFC2045</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>MIME-MEDIA</kw>
            <kw>headers</kw>
            <kw>structure</kw>
        </keywords>
        <abstract><p>This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]</p></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>
            <doc-id>RFC5147</doc-id>
            <doc-id>RFC6657</doc-id>
            <doc-id>RFC8098</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2046</errata-url>
        <doi>10.17487/RFC2046</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MIME-MSG</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2047</errata-url>
        <doi>10.17487/RFC2047</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>media</kw>
            <kw>types</kw>
            <kw>external</kw>
            <kw>body</kw>
            <kw>access</kw>
            <kw>content-transfer-encodings</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1521</doc-id>
            <doc-id>RFC1522</doc-id>
            <doc-id>RFC1590</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4288</doc-id>
            <doc-id>RFC4289</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3023</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <doi>10.17487/RFC2048</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MIME-CONF</kw>
            <kw>media</kw>
            <kw>type</kw>
            <kw>message</kw>
            <kw>formats</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>822ext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2049</errata-url>
        <doi>10.17487/RFC2049</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Addresses</kw>
            <kw>Network</kw>
            <kw>Numbers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1466</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7020</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2050</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>SNANAU-APP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2051</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS-SRV</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2782</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2052</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Top</kw>
            <kw>Level</kw>
            <kw>Domain</kw>
            <kw>Country</kw>
            <kw>Code</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2053</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>Fil</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2054</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>Fil</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2055</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>URLZ39.50</kw>
            <kw>URL</kw>
            <kw>information</kw>
            <kw>retrieval</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2056</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>content</kw>
            <kw>regulation</kw>
            <kw>deposition</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2057</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2138</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>nasreq</wg_acronym>
        <doi>10.17487/RFC2058</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial</kw>
            <kw>in</kw>
            <kw>user</kw>
            <kw>service</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2139</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2059</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <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><p>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2060</errata-url>
        <doi>10.17487/RFC2060</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1730</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2061</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2062</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>TFM-ARCH</kw>
            <kw>network</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2722</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2063</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>METER-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Network</kw>
            <kw>Data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2720</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2064</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>DNS-SEC</kw>
            <kw>DNS</kw>
            <kw>authentication</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2065</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TOPT-CHARSET</kw>
            <kw>character</kw>
            <kw>set</kw>
            <kw>application</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2066</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <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><p>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]</p></abstract>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2067</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>162</page-count>
        <keywords>
            <kw>HTTP-1.1</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
            <kw>WWW</kw>
            <kw>hypermedia</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2616</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <doi>10.17487/RFC2068</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DAA</kw>
            <kw>Hypertext</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2617</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2069</errata-url>
        <doi>10.17487/RFC2069</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>HTML-INT</kw>
            <kw>HTML</kw>
            <kw>WWW</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>html</wg_acronym>
        <doi>10.17487/RFC2070</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Enterprise</kw>
            <kw>Connecting</kw>
            <kw>Routers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>pier</wg_acronym>
        <doi>10.17487/RFC2071</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Enterprise</kw>
            <kw>Connecting</kw>
            <kw>Routers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC4192</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>pier</wg_acronym>
        <doi>10.17487/RFC2072</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPV6-UNI</kw>
        </keywords>
        <abstract><p>This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2374</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2073</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>RMON</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2895</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC2074</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IP-Echo</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>datagram</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2075</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>email</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mailext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2076</errata-url>
        <doi>10.17487/RFC2076</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>MIME-MODEL</kw>
            <kw>MIME</kw>
            <kw>Media</kw>
            <kw>Type</kw>
            <kw>Content</kw>
            <kw>Type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2077</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>GSSAP</kw>
            <kw>Authentication</kw>
            <kw>Cryptology</kw>
            <kw>Data</kw>
            <kw>integrity</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2078</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>URI-ATT</kw>
            <kw>URL</kw>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC2079</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RIPNG-IPV6</kw>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2080</errata-url>
        <doi>10.17487/RFC2080</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rip</wg_acronym>
        <doi>10.17487/RFC2081</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RIP2-MD5</kw>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4822</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <doi>10.17487/RFC2082</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>102</page-count>
        <keywords>
            <kw>PNG</kw>
            <kw>file</kw>
            <kw>format</kw>
            <kw>bitmap</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2083</errata-url>
        <doi>10.17487/RFC2083</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>encryption</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
            <kw>WWW</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>wts</wg_acronym>
        <doi>10.17487/RFC2084</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2085</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4314</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2086</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IMAP4-QUO</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC9208</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2087</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>IMAP4-LIT</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>The Internet Message Access Protocol [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7888</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4466</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2088</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2576</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2089</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TFTP-MULTI</kw>
            <kw>Trivial</kw>
            <kw>File</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2090</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>RIP-TRIG</kw>
        </keywords>
        <abstract><p>This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rip</wg_acronym>
        <doi>10.17487/RFC2091</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2092</errata-url>
        <doi>10.17487/RFC2092</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>GKMP-SPEC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2093</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>GKMP-ARCH</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2094</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
        </keywords>
        <abstract><p>This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2195</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2095</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>TABLE-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1354</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4292</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC2096</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PPP-NBFCP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2097</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Asynchronis</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
            <kw>datagram</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2098</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2099</doi>
    </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>1</day>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>April</kw>
            <kw>Fool's</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2100</errata-url>
        <doi>10.17487/RFC2100</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2101</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>scalable</kw>
            <kw>routing</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nimrod</wg_acronym>
        <doi>10.17487/RFC2102</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>routing</kw>
            <kw>addressing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nimrod</wg_acronym>
        <doi>10.17487/RFC2103</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>Message</kw>
            <kw>Digest</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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</p></abstract>
        <updated-by>
            <doc-id>RFC6151</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2104</errata-url>
        <doi>10.17487/RFC2104</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>network</kw>
            <kw>layer</kw>
            <kw>packet</kw>
            <kw>ATM</kw>
            <kw>switches</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2105</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DLSRAP</kw>
            <kw>NetBios</kw>
            <kw>DLSW</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2114</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2106</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2107</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>802.3-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract><p>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; 100 Mb/s Management," October 26, 1995.</p></abstract>
        <obsoletes>
            <doc-id>RFC1516</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC2108</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>HTTP-STATE</kw>
            <kw>Hypertext</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
            <kw>cookie</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2965</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <doi>10.17487/RFC2109</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2557</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhtml</wg_acronym>
        <doi>10.17487/RFC2110</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>URL</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2392</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhtml</wg_acronym>
        <doi>10.17487/RFC2111</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <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><p>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]</p></abstract>
        <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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhtml</wg_acronym>
        <doi>10.17487/RFC2112</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>ROUT-ALERT</kw>
        </keywords>
        <abstract><p>This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC5350</doc-id>
            <doc-id>RFC6398</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2113</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>DLSCAP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2106</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2114</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>FRAME-MIB</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1315</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2115</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>164</page-count>
        <keywords>
            <kw>Directory</kw>
            <kw>Services</kw>
            <kw>DSA</kw>
            <kw>DUA</kw>
            <kw>Agent</kw>
            <kw>Interfaces</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2116</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2362</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2117</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2118</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Standards</kw>
            <kw>Track</kw>
            <kw>Documents</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bradner-key-words-03</draft>
        <updated-by>
            <doc-id>RFC8174</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0014</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2119</errata-url>
        <doi>10.17487/RFC2119</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>X.500-NAME</kw>
            <kw>ISO</kw>
            <kw>International</kw>
            <kw>Standards</kw>
            <kw>Organization</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2120</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2121</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2122</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Meter</kw>
            <kw>Reader</kw>
            <kw>Network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2123</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>LFAP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2124</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>BAP-BACP</kw>
            <kw>Point-to-Point</kw>
            <kw>datagram</kw>
            <kw>multilink</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2125</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ITOT</kw>
            <kw>International</kw>
            <kw>Standards</kw>
            <kw>Organization</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC1006</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2126</errata-url>
        <doi>10.17487/RFC2126</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>isdnmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2127</errata-url>
        <doi>10.17487/RFC2127</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <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><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>isdnmib</wg_acronym>
        <doi>10.17487/RFC2128</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>packet</kw>
            <kw>flow</kw>
            <kw>datalink</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2129</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC6055</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2130</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>DHCPv4</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1541</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3396</doc-id>
            <doc-id>RFC4361</doc-id>
            <doc-id>RFC5494</doc-id>
            <doc-id>RFC6842</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2131</errata-url>
        <doi>10.17487/RFC2131</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>DHCP-BOOTP</kw>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Protocol</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1533</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3442</doc-id>
            <doc-id>RFC3942</doc-id>
            <doc-id>RFC4361</doc-id>
            <doc-id>RFC4833</doc-id>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2132</errata-url>
        <doi>10.17487/RFC2132</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
            <kw>API</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2553</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2133</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ISOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2134</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ISOC</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2135</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>DNS-UPDATE</kw>
            <kw>database</kw>
            <kw>opcode</kw>
            <kw>zone</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3007</doc-id>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2136</errata-url>
        <doi>10.17487/RFC2136</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SDNSDU</kw>
            <kw>DNS</kw>
            <kw>digital</kw>
            <kw>signatures</kw>
            <kw>cryptographic</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2137</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2138</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2139</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC9040</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2140</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>URN-SYNTAX</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Names</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC8141</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2141</errata-url>
        <doi>10.17487/RFC2141</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MAIL-SERV</kw>
            <kw>email</kw>
            <kw>internet</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2142</errata-url>
        <doi>10.17487/RFC2142</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IP-SCSI</kw>
            <kw>SCSI</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2143</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>CAST-128</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2144</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7230</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <doi>10.17487/RFC2145</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Gov</kw>
            <kw>FED.US</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1816</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2146</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2675</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2147</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>X. 500</kw>
            <kw>data structure</kw>
            <kw>naming scheme</kw>
            <kw>IWPS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0015</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2148</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2149</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>informational</kw>
            <kw>infrastructure</kw>
            <kw>guide</kw>
            <kw>introduction</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0031</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>harts</wg_acronym>
        <doi>10.17487/RFC2150</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>resource</kw>
            <kw>guide</kw>
            <kw>user</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2151</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>UTF-7</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1642</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2152</errata-url>
        <doi>10.17487/RFC2152</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>PPP-EXT</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1661</doc-id>
            <doc-id>RFC1962</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5342</doc-id>
            <doc-id>RFC7042</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2153</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>OSPF-DIG</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2154</errata-url>
        <doi>10.17487/RFC2154</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>APPN-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2455</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2155</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>144</page-count>
        <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><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2156</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2157</errata-url>
        <doi>10.17487/RFC2157</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2158</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2159</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2160</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>MIME-ODA</kw>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2161</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <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><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1405</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2162</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <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><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2163</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1838</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2164</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>SLP</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>svrloc</wg_acronym>
        <doi>10.17487/RFC2165</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2166</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>RWHOIS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1714</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2167</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <doi>10.17487/RFC2168</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver.</p><p> 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. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated resolution protocols are developed later.</p></abstract>
        <draft>draft-ietf-urn-http-conv-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <doi>10.17487/RFC2169</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2170</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MAPOS-SONET</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2171</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2172</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2173</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2174</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2175</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPV4-MAPOS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2176</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IMAP4-IDLE</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2177</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>211</page-count>
        <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><p>This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.</p><p> OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC2178</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>network</kw>
            <kw>system</kw>
            <kw>attacks</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2179</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Client</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2180</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DNS-CLAR</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC1123</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC4343</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC5452</doc-id>
            <doc-id>RFC8767</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2181</errata-url>
        <doi>10.17487/RFC2181</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>delegated</kw>
            <kw>zone</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0016</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2182</errata-url>
        <doi>10.17487/RFC2182</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>inline</kw>
            <kw>attachment</kw>
            <kw>MIME</kw>
            <kw>Mail</kw>
            <kw>Multimedia</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1806</doc-id>
        </obsoletes>
        <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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2183</errata-url>
        <doi>10.17487/RFC2183</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>mail</kw>
            <kw>Multimedia</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract><p>This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2184</errata-url>
        <doi>10.17487/RFC2184</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>address</kw>
            <kw>network</kw>
            <kw>tunneling</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2185</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ICP</kw>
            <kw>www</kw>
            <kw>web</kw>
            <kw>http</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2186</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>web</kw>
            <kw>www</kw>
            <kw>url</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2187</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>ESRO</kw>
            <kw>RPC</kw>
            <kw>Remote</kw>
            <kw>Procedure</kw>
            <kw>Call</kw>
            <kw>Wireless</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2188</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Inter-Domain-Protocol</kw>
            <kw>IDMR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2189</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract><p>This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2190</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>IP</kw>
            <kw>ATM</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2191</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <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><p>This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5092</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2192</errata-url>
        <doi>10.17487/RFC2192</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IMAP4MAIL</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>messages</kw>
        </keywords>
        <abstract><p>Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2193</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Server</kw>
            <kw>Provider</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>roamops</wg_acronym>
        <doi>10.17487/RFC2194</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IMAPPOPAU</kw>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
        </keywords>
        <abstract><p>This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC2095</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2195</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>ssh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2196</errata-url>
        <doi>10.17487/RFC2196</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2197</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RTP-RAD</kw>
        </keywords>
        <abstract><p>This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC6354</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2198</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2199</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></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>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2200</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IDMR</kw>
            <kw>Inter-Domain</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2201</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Hash</kw>
            <kw>Message</kw>
            <kw>Authentications</kw>
            <kw>Codes</kw>
            <kw>message</kw>
            <kw>digest</kw>
            <kw>secure</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2202</errata-url>
        <doi>10.17487/RFC2202</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <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><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC5403</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>oncrpc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2203</errata-url>
        <doi>10.17487/RFC2203</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>ODETTE</kw>
            <kw>FTP</kw>
            <kw>Internet</kw>
            <kw>Motor</kw>
            <kw>Industry</kw>
            <kw>data</kw>
            <kw>exchange</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5024</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2204</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>112</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>integrated</kw>
            <kw>services</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
            <kw>QoS</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC2750</doc-id>
            <doc-id>RFC3936</doc-id>
            <doc-id>RFC4495</doc-id>
            <doc-id>RFC5946</doc-id>
            <doc-id>RFC6437</doc-id>
            <doc-id>RFC6780</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2205</errata-url>
        <doi>10.17487/RFC2205</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>RSVP-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC2206</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>RSVP-IPSEC</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>QoS</kw>
            <kw>IP</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC2207</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>RSVP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC2208</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>RSVP-MPR</kw>
            <kw>QoS</kw>
            <kw>implementation</kw>
            <kw>algorithms</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2209</errata-url>
        <doi>10.17487/RFC2209</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <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><p>This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC2210</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>QOS: Quality of Service</kw>
            <kw>integrated services</kw>
        </keywords>
        <abstract><p>This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC2211</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>GQOS</kw>
            <kw>QOS</kw>
            <kw>quality of service</kw>
            <kw>integrated services</kw>
        </keywords>
        <abstract><p>This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC2212</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2213</errata-url>
        <doi>10.17487/RFC2213</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>attributes</kw>
            <kw>interface</kw>
            <kw>network</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC2214</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>QOS</kw>
            <kw>Quality of service</kw>
        </keywords>
        <abstract><p>This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC2215</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>QOS</kw>
            <kw>Quality</kw>
            <kw>of</kw>
            <kw>Service</kw>
            <kw>Control</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC2216</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>TOPT-COMPORT</kw>
            <kw>remote</kw>
            <kw>login</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2217</errata-url>
        <doi>10.17487/RFC2217</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IWPS</kw>
            <kw>information</kw>
            <kw>user</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2218</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>symbolic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0017</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2219</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>APP-MARC</kw>
            <kw>media-type</kw>
            <kw>machine</kw>
            <kw>readable</kw>
            <kw>cataloging</kw>
            <kw>records</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2220</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IMAP4LOGIN</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2221</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SASL</kw>
            <kw>encryption</kw>
            <kw>protocol</kw>
            <kw>specific</kw>
        </keywords>
        <abstract><p>This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4422</doc-id>
            <doc-id>RFC4752</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2444</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2222</errata-url>
        <doi>10.17487/RFC2222</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Request</kw>
            <kw>For</kw>
            <kw>Comment</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1543</doc-id>
            <doc-id>RFC1111</doc-id>
            <doc-id>RFC0825</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7322</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5741</doc-id>
            <doc-id>RFC6949</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2223</errata-url>
        <doi>10.17487/RFC2223</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2224</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <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><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1626</doc-id>
            <doc-id>RFC1577</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2225</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2226</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <doi>10.17487/RFC2227</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>FTPSECEXT</kw>
            <kw>file transfer protocol</kw>
            <kw>authentication</kw>
            <kw>encoding</kw>
        </keywords>
        <abstract><p>This document defines extensions to the FTP specification STD 9, RFC</p></abstract>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2228</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2229</errata-url>
        <doi>10.17487/RFC2229</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2230</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MIME-EXT</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>Multimedia</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2231</errata-url>
        <doi>10.17487/RFC2231</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>DLUR-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>Dependent LU Requester</kw>
            <kw>APPN</kw>
            <kw>Advanced Peer-to-Peer Networking</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2232</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>INTERGRMIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Network</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC2233</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ABNF</kw>
            <kw>Augmented</kw>
            <kw>Backus-Naur</kw>
            <kw>Form</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4234</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>drums</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2234</errata-url>
        <doi>10.17487/RFC2234</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>events</kw>
            <kw>technologies</kw>
            <kw>history</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0032</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2235</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IGMP</kw>
            <kw>IGMP</kw>
            <kw>multicast</kw>
            <kw>routing</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers.  It updates STD 5, RFC 1112. [STANDARDS-TRACK]</p></abstract>
        <updates>
            <doc-id>RFC1112</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3376</doc-id>
            <doc-id>RFC9776</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2236</errata-url>
        <doi>10.17487/RFC2236</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>eletronic</kw>
            <kw>mail</kw>
            <kw>character</kw>
            <kw>set</kw>
            <kw>scheme</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2237</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>HPR-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>high performance routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2238</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>MAUS-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2668</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC2239</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2352</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2240</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DHCP-NDS</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>Novell Directory Services</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC2241</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>NETWAREIP</kw>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>NetWare/IP</kw>
        </keywords>
        <abstract><p>This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC2242</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>OTP-ER</kw>
            <kw>One Time Password</kw>
            <kw>Extended Responses</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>otp</wg_acronym>
        <doi>10.17487/RFC2243</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>ACAP</kw>
            <kw>Application Configuration Access Protocol</kw>
            <kw>URL</kw>
            <kw>Uniform Resource Locator</kw>
        </keywords>
        <abstract><p>The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC6075</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>acap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2244</errata-url>
        <doi>10.17487/RFC2244</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>SASL-ANON</kw>
            <kw>Simple</kw>
            <kw>Authentication</kw>
            <kw>Security</kw>
            <kw>Layer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4505</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>acap</wg_acronym>
        <doi>10.17487/RFC2245</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>layer</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4346</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3546</doc-id>
            <doc-id>RFC5746</doc-id>
            <doc-id>RFC6176</doc-id>
            <doc-id>RFC7465</doc-id>
            <doc-id>RFC7507</doc-id>
            <doc-id>RFC7919</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2246</errata-url>
        <doi>10.17487/RFC2246</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>DNS</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC4519</doc-id>
            <doc-id>RFC4524</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC2247</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC2248</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <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><p>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 [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC2249</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>RTP-MPEG</kw>
            <kw>Real-Time Transport Protocol</kw>
            <kw>Audio</kw>
            <kw>System</kw>
            <kw>Streams</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2038</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2250</errata-url>
        <doi>10.17487/RFC2250</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>LDAPV3</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>x.500</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4510</doc-id>
            <doc-id>RFC4511</doc-id>
            <doc-id>RFC4513</doc-id>
            <doc-id>RFC4512</doc-id>
        </obsoleted-by>
        <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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC2251</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>LDAP3-ATD</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4510</doc-id>
            <doc-id>RFC4517</doc-id>
            <doc-id>RFC4523</doc-id>
            <doc-id>RFC4512</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2252</errata-url>
        <doi>10.17487/RFC2252</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>LDAP3-UTF8</kw>
            <kw>LDAPv3</kw>
            <kw>x.500</kw>
            <kw>ASN.1</kw>
            <kw>string</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1779</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4510</doc-id>
            <doc-id>RFC4514</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2253</errata-url>
        <doi>10.17487/RFC2253</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>STR-LDAP</kw>
            <kw>LDAPv3</kw>
            <kw>x.500</kw>
            <kw>ASN.1</kw>
            <kw>string</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1960</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4510</doc-id>
            <doc-id>RFC4515</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2254</errata-url>
        <doi>10.17487/RFC2254</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1959</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4510</doc-id>
            <doc-id>RFC4516</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC2255</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Lightweight</kw>
            <kw>Directory</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4517</doc-id>
            <doc-id>RFC4519</doc-id>
            <doc-id>RFC4523</doc-id>
            <doc-id>RFC4512</doc-id>
            <doc-id>RFC4510</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <doi>10.17487/RFC2256</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2741</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>agentx</wg_acronym>
        <doi>10.17487/RFC2257</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Database</kw>
            <kw>Server</kw>
            <kw>CCSO</kw>
            <kw>Computer</kw>
            <kw>Communications</kw>
            <kw>Services</kw>
            <kw>Office</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2258</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>SNQP</kw>
            <kw>Data</kw>
            <kw>Repositories</kw>
            <kw>Client</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2259</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2260</errata-url>
        <doi>10.17487/RFC2260</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2271</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2261</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>architecture</kw>
            <kw>SNMPv3</kw>
            <kw>multiple</kw>
            <kw>versions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2272</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2262</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2273</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2263</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>architecture</kw>
            <kw>message</kw>
            <kw>level</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2274</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2264</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SNMPV3</kw>
            <kw>Architecture</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2275</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2265</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>vgmib</wg_acronym>
        <doi>10.17487/RFC2266</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>DOS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2827</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2267</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RC2-ENCRP</kw>
            <kw>encryption</kw>
            <kw>secre</kw>
            <kw>key rsa</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2268</errata-url>
        <doi>10.17487/RFC2268</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2269</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2270</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <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><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2271</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>SNMPv3</kw>
            <kw>architecture</kw>
            <kw>SNMPv3</kw>
            <kw>multiple</kw>
            <kw>versions</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2272</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <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><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2273</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>architecture</kw>
            <kw>message</kw>
            <kw>level</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2274</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SNMPV3</kw>
            <kw>Architecture</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2275</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>URCs</kw>
            <kw>URN</kw>
            <kw>URLs</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
            <kw>Characteristics</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC3401</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <doi>10.17487/RFC2276</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>charset</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0018</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2277</errata-url>
        <doi>10.17487/RFC2277</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>character</kw>
            <kw>set</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2978</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2278</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>UTF-8</kw>
            <kw>UCS</kw>
            <kw>Transformation</kw>
            <kw>Format</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2279</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>RPSL</kw>
            <kw>network</kw>
            <kw>operator</kw>
            <kw>AS</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
            <kw>database</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2622</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <doi>10.17487/RFC2280</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>HSRP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2281</errata-url>
        <doi>10.17487/RFC2281</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>Engineering</kw>
            <kw>Steering</kw>
            <kw>Group</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC2282</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2858</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2283</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>PPP-EAP</kw>
            <kw>point-to-point</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2284</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC2285</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>has</kw>
            <kw>authentication</kw>
            <kw>message</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>codes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2286</errata-url>
        <doi>10.17487/RFC2286</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>SLM-APP</kw>
            <kw>System-Level Managed Objects for Applications</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>applmib</wg_acronym>
        <doi>10.17487/RFC2287</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>URNs</kw>
            <kw>Syntax</kw>
            <kw>framework</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2288</errata-url>
        <doi>10.17487/RFC2288</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ONE-PASS</kw>
            <kw>one-time password authentication system</kw>
            <kw>OTP</kw>
            <kw>replay</kw>
            <kw>attach</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1938</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0061</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>otp</wg_acronym>
        <doi>10.17487/RFC2289</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Mobile-IPv4</kw>
            <kw>address</kw>
            <kw>PPP</kw>
            <kw>Point-to-Point Protocol</kw>
            <kw>IPCP</kw>
            <kw>Internet Protocol Control Protocol</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2290</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>WWW</kw>
            <kw>remote</kw>
            <kw>editing</kw>
            <kw>locking</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <doi>10.17487/RFC2291</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3542</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2292</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SUBTABLE</kw>
            <kw>mapping</kw>
            <kw>distinguished</kw>
            <kw>name</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1837</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2293</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>OR-ADD</kw>
            <kw>O/R address</kw>
            <kw>routing</kw>
            <kw>mapping</kw>
            <kw>X.500</kw>
            <kw>Directory Information Tree</kw>
        </keywords>
        <abstract><p>This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1836</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mixer</wg_acronym>
        <doi>10.17487/RFC2294</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>TCN-HTTP</kw>
            <kw>Transparent Content Negotiation</kw>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>URL</kw>
            <kw>Uniform Resource Locators</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <doi>10.17487/RFC2295</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-http-rvsa-v10-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2296</errata-url>
        <doi>10.17487/RFC2296</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <keywords>
            <kw>GSMP</kw>
            <kw>gsmp</kw>
            <kw>atm</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1987</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2297</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3798</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>receipt</wg_acronym>
        <doi>10.17487/RFC2298</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2299</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2200</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2400</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2300</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3949</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2301</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TIFF</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3302</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2302</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MIN-PSTN</kw>
            <kw>e-mail</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3191</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2303</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MINFAX-IM</kw>
            <kw>encoding</kw>
            <kw>facsimile</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract><p>This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3192</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2304</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SMFAX-IM</kw>
            <kw>data</kw>
            <kw>file</kw>
            <kw>format</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract><p>This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3965</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2305</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>file</kw>
            <kw>format</kw>
            <kw>storage</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2306</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>LDAP-NIS</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>Network Information Service</kw>
            <kw>unix</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2307</errata-url>
        <doi>10.17487/RFC2307</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNS-NCACHE</kw>
            <kw>Domain Name System</kw>
            <kw>negative</kw>
            <kw>queries</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC6604</doc-id>
            <doc-id>RFC8020</doc-id>
            <doc-id>RFC8499</doc-id>
            <doc-id>RFC9499</doc-id>
            <doc-id>RFC9520</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2308</errata-url>
        <doi>10.17487/RFC2308</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>performance</kw>
            <kw>router</kw>
            <kw>deployment</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7567</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7141</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2309</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>http</kw>
            <kw>hyper</kw>
            <kw>text</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe.  Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.</p></abstract>
        <draft>draft-holtman-http-safe-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <doi>10.17487/RFC2310</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>SMIME-MSG</kw>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2311</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>SMIME-CERT</kw>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2312</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>PKCS-1</kw>
            <kw>data</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2437</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2313</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2986</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2314</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2315</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Board</kw>
            <kw>protocols</kw>
            <kw>tools</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2316</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>mapping</kw>
            <kw>addresses</kw>
            <kw>zone</kw>
            <kw>files</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0020</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2317</errata-url>
        <doi>10.17487/RFC2317</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>TEXT-CSS</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2318</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>KOI8-U</kw>
            <kw>encoding</kw>
            <kw>mail</kw>
            <kw>information</kw>
            <kw>resources</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2319</errata-url>
        <doi>10.17487/RFC2319</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>IPOA-MIB</kw>
            <kw>Classical IP and ARP over ATM</kw>
            <kw>management information base</kw>
            <kw>internet protocol</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2320</doi>
    </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>1</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>networking</kw>
            <kw>environments</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC2321</doi>
    </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>1</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>HIP</kw>
            <kw>Hacking</kw>
            <kw>in</kw>
            <kw>progress</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2322</errata-url>
        <doi>10.17487/RFC2322</doi>
    </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>1</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>facial</kw>
            <kw>hairius</kw>
            <kw>extremis</kw>
            <kw>FHE</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC2323</doi>
    </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>1</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>controlling</kw>
            <kw>monitoring</kw>
            <kw>diagnosing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC7168</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2324</errata-url>
        <doi>10.17487/RFC2324</doi>
    </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>1</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>coffee</kw>
            <kw>brewing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2325</errata-url>
        <doi>10.17487/RFC2325</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>RTSP</kw>
            <kw>Real Time Streaming Protocol</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>data</kw>
            <kw>delivery</kw>
            <kw>application</kw>
            <kw>level</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7826</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2326</errata-url>
        <doi>10.17487/RFC2326</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>mbone</kw>
            <kw>internet</kw>
            <kw>multicast</kw>
            <kw>backbone</kw>
            <kw>multimedia</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4566</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3266</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2327</errata-url>
        <doi>10.17487/RFC2327</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>244</page-count>
        <keywords>
            <kw>OSPF2</kw>
            <kw>Open Shortest Path First</kw>
            <kw>routing</kw>
            <kw>Autonomous system</kw>
            <kw>AS</kw>
        </keywords>
        <abstract><p>This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC2178</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5709</doc-id>
            <doc-id>RFC6549</doc-id>
            <doc-id>RFC6845</doc-id>
            <doc-id>RFC6860</doc-id>
            <doc-id>RFC7474</doc-id>
            <doc-id>RFC8042</doc-id>
            <doc-id>RFC9355</doc-id>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0054</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2328</errata-url>
        <doi>10.17487/RFC2328</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC2329</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>measurement</kw>
            <kw>statistics</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC7312</doc-id>
            <doc-id>RFC8468</doc-id>
            <doc-id>RFC9198</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC2330</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>UNI-SIG</kw>
            <kw>signalling</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2331</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>NHRP</kw>
            <kw>Next Hop Resolution Protocol</kw>
            <kw>internetworking</kw>
            <kw>layer</kw>
            <kw>address</kw>
            <kw>subnetwork</kw>
            <kw>multiprotocol</kw>
            <kw>NBMA</kw>
            <kw>non-broadcast</kw>
            <kw>multiple-access</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2332</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>NHRP</kw>
            <kw>next hop resolution protocol</kw>
            <kw>routing</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw> NBMA</kw>
            <kw>non-broadcast</kw>
            <kw>multiple-access</kw>
            <kw>internetworking</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2333</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>SCSP</kw>
            <kw>Server Cache Synchronization Protocol</kw>
            <kw>replication</kw>
            <kw>NBMA</kw>
            <kw>non-broadcast</kw>
            <kw>multiple access</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2334</errata-url>
        <doi>10.17487/RFC2334</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>NHRP-SCSP</kw>
            <kw>next hop resolution protocol</kw>
            <kw>server cache synchronization protocol</kw>
        </keywords>
        <abstract><p>This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2336</doc-id>
        <title>Classical IP and ARP over ATM to NHRP Transition</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2336</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>PIM</kw>
            <kw>Protocol Independent Multicast</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2337</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3768</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>vrrp</wg_acronym>
        <doi>10.17487/RFC2338</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2339</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>packet</kw>
            <kw>switching</kw>
            <kw>multi-protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2340</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>L2F</kw>
            <kw>Layer Two Forwarding</kw>
            <kw>protocol</kw>
            <kw>tunneling</kw>
            <kw>dial-up</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2341</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IMAP4NAME</kw>
            <kw>internet message access protocol</kw>
            <kw>namespace</kw>
            <kw>mailbox</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC4466</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2342</errata-url>
        <doi>10.17487/RFC2342</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RTP-MPEG</kw>
            <kw>real-time transport protocol</kw>
            <kw>audio</kw>
            <kw>video</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2343</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3024</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC2344</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>URL</kw>
            <kw>mapping</kw>
            <kw>service</kw>
            <kw>whois</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2345</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>portable</kw>
            <kw>document</kw>
            <kw>format</kw>
            <kw>document</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2346</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TFTP-Ext</kw>
            <kw>trivial file transfer protocol</kw>
            <kw>extension</kw>
            <kw>booting</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2347</errata-url>
        <doi>10.17487/RFC2347</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>TFTP-Blk</kw>
            <kw>trivial file transfer protocol</kw>
            <kw>booting</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2348</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>TFTP-Opt</kw>
            <kw>trivial file transfer protocol</kw>
            <kw>booting</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2349</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2350</errata-url>
        <doi>10.17487/RFC2350</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>encapsulation</kw>
            <kw>transactional</kw>
            <kw>traffic</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2351</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2240</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2352</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2353</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>packets</kw>
            <kw>UDP</kw>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2354</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>TN3270E</kw>
            <kw>Telnet</kw>
            <kw>option</kw>
            <kw>client</kw>
        </keywords>
        <abstract><p>This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1647</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6270</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2355</errata-url>
        <doi>10.17487/RFC2355</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>security</kw>
            <kw>traffic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC2356</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
            <kw>rmtp</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2357</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>802.3</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC2358</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IMAP4UIDPL</kw>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>disconnected</kw>
            <kw>operation</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4315</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2359</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>specification</kw>
            <kw>multiple</kw>
            <kw>implementations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0022</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>stdguide</wg_acronym>
        <doi>10.17487/RFC2360</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>multimedia</kw>
            <kw>parameter</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>microsoft</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2361</errata-url>
        <doi>10.17487/RFC2361</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>PIM-SM</kw>
            <kw>Protocol Independent Multicast-Sparse Mode</kw>
            <kw>routing</kw>
            <kw>message</kw>
            <kw>type</kw>
            <kw>timers</kw>
            <kw>flags</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2117</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4601</doc-id>
            <doc-id>RFC5059</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2362</errata-url>
        <doi>10.17487/RFC2362</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>PPP-FUNI</kw>
            <kw>point-to-point protocol</kw>
            <kw>Frame User Interface</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract><p>This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2363</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>PPP-AAL</kw>
            <kw>point-to-point protocol</kw>
            <kw>ATM Adaption Layer 5</kw>
            <kw>link</kw>
            <kw>control</kw>
            <kw>network-layer</kw>
            <kw>authentication</kw>
            <kw>compression</kw>
        </keywords>
        <abstract><p>This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2364</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>IPv4</kw>
            <kw>ipv6</kw>
            <kw>address</kw>
            <kw>classes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0023</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC2365</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2417</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2366</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>application</kw>
            <kw>programming</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2367</errata-url>
        <doi>10.17487/RFC2367</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>URLMAILTO</kw>
            <kw>uniform resource locator</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6068</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1738</doc-id>
            <doc-id>RFC1808</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2368</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>URL</kw>
            <kw>uniform resource locator</kw>
            <kw>email</kw>
            <kw>header</kw>
            <kw>fields</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2369</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>OSPF-LSA</kw>
            <kw>open shortest path first</kw>
            <kw>link state advertisement</kw>
        </keywords>
        <abstract><p>This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5250</doc-id>
        </obsoleted-by>
        <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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC2370</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>TIPV3</kw>
            <kw>Transaction Internet Protocol</kw>
            <kw>commit</kw>
            <kw>electronic</kw>
            <kw>commerce</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tip</wg_acronym>
        <doi>10.17487/RFC2371</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>TIP</kw>
            <kw>commit</kw>
            <kw>protocol</kw>
            <kw>electronic</kw>
            <kw>commerce</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tip</wg_acronym>
        <doi>10.17487/RFC2372</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>unicast</kw>
            <kw>anycast</kw>
            <kw>multicast</kw>
            <kw>node</kw>
        </keywords>
        <abstract><p>This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2373</errata-url>
        <doi>10.17487/RFC2373</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>address</kw>
            <kw>architecture</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2374</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>multicast</kw>
            <kw>scope</kw>
            <kw>value</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2375</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3023</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2376</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>x.500</kw>
            <kw>applications</kw>
            <kw>iwps</kw>
            <kw>white</kw>
            <kw>pages</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC4519</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2377</errata-url>
        <doi>10.17487/RFC2377</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>computing</kw>
            <kw>communications</kw>
            <kw>services</kw>
            <kw>office</kw>
            <kw>database</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ids</wg_acronym>
        <doi>10.17487/RFC2378</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0024</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2379</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw> resource reservation protocol</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>switched</kw>
            <kw>circuits</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2380</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>mapping</kw>
            <kw>traffic</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract><p>This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2381</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2382</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>stream</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2383</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>POP-URL</kw>
            <kw>post office protocol</kw>
            <kw>uniform resource locator</kw>
            <kw>identifier</kw>
            <kw>string</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2384</errata-url>
        <doi>10.17487/RFC2384</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>border gateway protocol</kw>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>message</kw>
            <kw>digest</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract><p>This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5925</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6691</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2385</errata-url>
        <doi>10.17487/RFC2385</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>quality of service</kw>
            <kw>interdomain</kw>
            <kw>intradomain</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>qosr</wg_acronym>
        <doi>10.17487/RFC2386</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MIME-RELAT</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>body</kw>
            <kw>parts</kw>
            <kw>media-type</kw>
        </keywords>
        <abstract><p>This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC2112</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhtml</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2387</errata-url>
        <doi>10.17487/RFC2387</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>media-type</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC7578</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2388</errata-url>
        <doi>10.17487/RFC2388</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>File Transfer Protocol</kw>
            <kw>catalogue</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <see-also>
            <doc-id>RFC0959</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ftpext</wg_acronym>
        <doi>10.17487/RFC2389</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IARP</kw>
            <kw>Inverse Address Resolution Protocol</kw>
            <kw>hardware</kw>
            <kw>frame</kw>
            <kw>relay</kw>
        </keywords>
        <abstract><p>This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1293</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2390</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>datagram</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2391</errata-url>
        <doi>10.17487/RFC2391</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>CIDMID-URL</kw>
            <kw>HTML</kw>
            <kw>Hypertext Markup Language</kw>
            <kw>URL</kw>
            <kw>Uniform Resource Locator</kw>
            <kw>MIME</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2111</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhtml</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2392</errata-url>
        <doi>10.17487/RFC2392</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPCOMP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>datagram</kw>
            <kw>lossless</kw>
        </keywords>
        <abstract><p>This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3173</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ippcp</wg_acronym>
        <doi>10.17487/RFC2393</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>algorithm</kw>
            <kw>datagram</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ippcp</wg_acronym>
        <doi>10.17487/RFC2394</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>algorithm</kw>
            <kw>datagram</kw>
            <kw>lossless</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ippcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2395</errata-url>
        <doi>10.17487/RFC2395</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>URI-GEN</kw>
            <kw>characters</kw>
            <kw>string</kw>
            <kw>absolute</kw>
            <kw>relative</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2396</errata-url>
        <doi>10.17487/RFC2396</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DATA-URL</kw>
            <kw>uniform resource locator</kw>
            <kw>identifiers</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2397</errata-url>
        <doi>10.17487/RFC2397</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>catalogue</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0033</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2398</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2399</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2300</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2500</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2400</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <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><p>This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1825</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4301</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3168</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2401</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <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><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1826</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4302</doc-id>
            <doc-id>RFC4305</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2402</errata-url>
        <doi>10.17487/RFC2402</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>HMAC</kw>
            <kw>MD5</kw>
            <kw>IPSEC</kw>
            <kw>Internet Protocol Security</kw>
            <kw>AH</kw>
            <kw>Authentication Header</kw>
            <kw>ESP</kw>
            <kw>Encapsulating Security Payload</kw>
            <kw>mechanism</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2403</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>mechanism</kw>
            <kw>header</kw>
            <kw>security</kw>
            <kw>architecture</kw>
            <kw>payload</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2404</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ESPDES-CBC</kw>
            <kw>IPSEC</kw>
            <kw>Internet Protocol Security</kw>
            <kw>Encapsulating Security Payload</kw>
            <kw>architecture</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2405</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <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><p>The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1827</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4303</doc-id>
            <doc-id>RFC4305</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2406</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4306</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2407</errata-url>
        <doi>10.17487/RFC2407</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>ISAKMP</kw>
            <kw>ipsec</kw>
            <kw>cryptography</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4306</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2408</errata-url>
        <doi>10.17487/RFC2408</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4306</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4109</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2409</errata-url>
        <doi>10.17487/RFC2409</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>internet protocol security</kw>
            <kw>esp</kw>
            <kw>encapsulating security payload</kw>
            <kw>NULL</kw>
        </keywords>
        <abstract><p>This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2410</errata-url>
        <doi>10.17487/RFC2410</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>privacy</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6071</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2411</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>crytographic</kw>
            <kw>secure</kw>
            <kw>scalable</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2412</errata-url>
        <doi>10.17487/RFC2412</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>workshop</kw>
            <kw>electronic</kw>
            <kw>librarians</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5013</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2413</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>TCP-WIN</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3390</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2414</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>file</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2415</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2416</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2366</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2417</errata-url>
        <doi>10.17487/RFC2417</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>BCP</kw>
            <kw>WG</kw>
            <kw>escape</kw>
            <kw>clause</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1603</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3934</doc-id>
            <doc-id>RFC7475</doc-id>
            <doc-id>RFC7776</doc-id>
            <doc-id>RFC8717</doc-id>
            <doc-id>RFC9141</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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2418</errata-url>
        <doi>10.17487/RFC2418</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DESE-bis</kw>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>DES Encryption Protocol</kw>
            <kw>ECP</kw>
            <kw>PPP Encryption Control Protocol</kw>
        </keywords>
        <abstract><p>This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1969</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2419</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>3DESE</kw>
            <kw>PPP Triple-DES Encryption Protocol</kw>
            <kw>point-to-point protocol</kw>
            <kw>ecp</kw>
            <kw>PPP Encryption Control Protocol</kw>
        </keywords>
        <abstract><p>This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2420</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>MIME-VP2</kw>
            <kw>vpim</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract><p>This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2421</errata-url>
        <doi>10.17487/RFC2421</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MIME-ADPCM</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>audio</kw>
        </keywords>
        <abstract><p>This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2422</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MIME-VPIM</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>Voice Profile for Internet Mail</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2423</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <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><p>This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3803</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2424</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>TXT-DIR</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>profiles</kw>
        </keywords>
        <abstract><p>This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6350</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2425</errata-url>
        <doi>10.17487/RFC2425</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>MIME-VCARD</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>white-pages</kw>
            <kw>electronic</kw>
            <kw>business</kw>
            <kw>card</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6350</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>asid</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2426</errata-url>
        <doi>10.17487/RFC2426</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>IP-FR</kw>
            <kw>Internet Protocol</kw>
            <kw>Frame Relay</kw>
            <kw>bridging</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1490</doc-id>
            <doc-id>RFC1294</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0055</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2427</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>file transfer protocol</kw>
            <kw>IPv6</kw>
            <kw>internet protocol version 6</kw>
            <kw>NATs</kw>
            <kw>network address translators</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ftpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2428</errata-url>
        <doi>10.17487/RFC2428</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>real</kw>
            <kw>time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4629</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2429</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2430</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>ITU</kw>
            <kw>International Telecommunication Union</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2431</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>forwarding</kw>
            <kw>devices</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC2432</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>point to point</kw>
            <kw>protocol</kw>
            <kw>challenge</kw>
            <kw>handshake</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2433</errata-url>
        <doi>10.17487/RFC2433</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>values</kw>
            <kw>implementations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5226</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3692</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC2434</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-Time Transport Protocol</kw>
            <kw>JPEG</kw>
            <kw>Joint Photographic Experts Group</kw>
        </keywords>
        <abstract><p>This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC2035</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2435</errata-url>
        <doi>10.17487/RFC2435</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>society</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract><p>This document describes the collaboration process between the ITU-T and ISOC/IETF.  This memo provides information for the Internet community.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3356</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2436</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>data</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2437</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0027</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC2438</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>Border Gateway Protocol</kw>
            <kw>IDRP</kw>
            <kw>Internet-Domain Routing Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2439</errata-url>
        <doi>10.17487/RFC2439</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>PGP</kw>
            <kw>pretty good privacy</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4880</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>openpgp</wg_acronym>
        <doi>10.17487/RFC2440</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Jonathan B Postel</kw>
        </keywords>
        <abstract><p>This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2441</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2442</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>MARS-SCSP</kw>
            <kw>server cache synchronization protocol</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2443</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>OTP-SASL</kw>
            <kw>One-Time Password</kw>
            <kw>simple authentication security layer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC2222</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>otp</wg_acronym>
        <doi>10.17487/RFC2444</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>148</page-count>
        <keywords>
            <kw>ICALENDAR</kw>
            <kw>interoperable</kw>
            <kw>mime</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5545</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2445</errata-url>
        <doi>10.17487/RFC2445</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <keywords>
            <kw>ITIP</kw>
            <kw>iCalendar Transport-Independent Interoperability Protocol</kw>
            <kw>internet</kw>
            <kw>systems</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC5546</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2446</errata-url>
        <doi>10.17487/RFC2446</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>IMIP</kw>
            <kw>iCalendar Message-Based Interoperability Protocol</kw>
            <kw>internet</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>transport</kw>
        </keywords>
        <abstract><p>This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6047</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsch</wg_acronym>
        <doi>10.17487/RFC2447</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>packets</kw>
            <kw>network</kw>
            <kw>bitstreams</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2448</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>POP3-EXT</kw>
            <kw>post office protocol</kw>
            <kw>server</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]</p></abstract>
        <updates>
            <doc-id>RFC1939</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5034</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2449</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2450</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ESP</kw>
            <kw>encapsulating security payload</kw>
            <kw>ipsec</kw>
            <kw>Internet Protocol Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2451</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>tcp</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4022</doc-id>
            <doc-id>RFC8096</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2452</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>RIP2</kw>
            <kw>RIP-2</kw>
            <kw>Routing Information Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1723</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4822</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0056</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ripv2</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2453</errata-url>
        <doi>10.17487/RFC2453</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>ipv6</kw>
            <kw>internet protocol</kw>
            <kw>UDP</kw>
            <kw>User Datagram Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4113</doc-id>
            <doc-id>RFC8096</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2454</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>140</page-count>
        <keywords>
            <kw>APPN-MIB</kw>
            <kw>Advanced Peer-to-Peer Networking</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2155</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2455</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>APPN</kw>
            <kw>advanced peer-to-peer networking</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2456</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>EBN-MIB</kw>
            <kw>Extended Border Node</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2457</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pint</wg_acronym>
        <doi>10.17487/RFC2458</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>129</page-count>
        <keywords>
            <kw>digital</kw>
            <kw>signatures</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3280</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2459</errata-url>
        <doi>10.17487/RFC2459</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>IPV6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>next</kw>
            <kw>generation</kw>
            <kw>ipng</kw>
        </keywords>
        <abstract><p>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipngwg-ipv6-spec-v2-02</draft>
        <obsoletes>
            <doc-id>RFC1883</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8200</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5095</doc-id>
            <doc-id>RFC5722</doc-id>
            <doc-id>RFC5871</doc-id>
            <doc-id>RFC6437</doc-id>
            <doc-id>RFC6564</doc-id>
            <doc-id>RFC6935</doc-id>
            <doc-id>RFC6946</doc-id>
            <doc-id>RFC7045</doc-id>
            <doc-id>RFC7112</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2460</errata-url>
        <doi>10.17487/RFC2460</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>93</page-count>
        <keywords>
            <kw>IPV6-ND</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>link-layer</kw>
        </keywords>
        <abstract><p>This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1970</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4861</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4311</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2461</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>IPV6-AUTO</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>host</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract><p>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1971</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4862</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2462</errata-url>
        <doi>10.17487/RFC2462</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ICMPv6</kw>
            <kw>Internet Control Message Protocol</kw>
            <kw>link-local</kw>
            <kw>autoconfigured</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1885</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4443</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2463</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>link-local</kw>
            <kw>autoconfigured</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC1972</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6085</doc-id>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2464</errata-url>
        <doi>10.17487/RFC2464</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4293</doc-id>
            <doc-id>RFC8096</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2465</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ICMPv6-MIB</kw>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4293</doc-id>
            <doc-id>RFC8096</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2466</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>link-local</kw>
            <kw>addresses</kw>
            <kw>autoconfiguration</kw>
            <kw>FDDI</kw>
            <kw>Fiber Distributed Data Interface</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2019</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2467</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>jonathan b postel</kw>
        </keywords>
        <abstract><p>A long time ago, in a network, far far away, a great adventure took place!.  This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2468</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>data</kw>
            <kw>fields</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2469</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>link-local</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2470</doi>
    </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</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>protocol type</kw>
            <kw>software</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2471</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IPv6-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-ipv6-over-ppp-06</draft>
        <obsoletes>
            <doc-id>RFC2023</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5072</doc-id>
            <doc-id>RFC5172</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2472</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2473</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>nodes</kw>
        </keywords>
        <abstract><p>This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC1455</doc-id>
            <doc-id>RFC1349</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0791</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3168</doc-id>
            <doc-id>RFC3260</doc-id>
            <doc-id>RFC8436</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2474</errata-url>
        <doi>10.17487/RFC2474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2475</doc-id>
        <title>An Architecture for Differentiated Services</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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>DIFFSRV</kw>
            <kw>Differentiated Services</kw>
            <kw>scalability</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>This document defines an architecture for implementing scalable service differentiation in the Internet.  This memo provides information for the Internet community.</p></abstract>
        <updated-by>
            <doc-id>RFC3260</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC2475</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>user</kw>
            <kw>agent</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4409</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2476</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>internet</kw>
            <kw>service</kw>
            <kw>providers</kw>
            <kw>operations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>roamops</wg_acronym>
        <doi>10.17487/RFC2477</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>generic</kw>
            <kw>service</kw>
            <kw>application</kw>
            <kw>security</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4178</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2478</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>data</kw>
            <kw>unit</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2479</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2480</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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><p>This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3168</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2481</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>characters</kw>
            <kw>strings</kw>
            <kw>ASCII</kw>
        </keywords>
        <abstract><p>This document proposed a mechanism for language tagging in plain text.  This memo provides information for the Internet community.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC6082</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2482</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>URI</kw>
            <kw>uniform resource identifier</kw>
            <kw>URN</kw>
            <kw>uniform resource names</kw>
            <kw>locators</kw>
            <kw>characteristics</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <doi>10.17487/RFC2483</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>LCP</kw>
            <kw>Link Control Protocol</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2484</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>UAP</kw>
            <kw>User Authentication Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC2485</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>NAI</kw>
            <kw>tunneling</kw>
            <kw>roaming</kw>
        </keywords>
        <abstract><p>This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4282</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>roamops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2486</errata-url>
        <doi>10.17487/RFC2486</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3207</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2487</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>BCP0028</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpsat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2488</errata-url>
        <doi>10.17487/RFC2488</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>mutipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2489</errata-url>
        <doi>10.17487/RFC2489</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>ipv4</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2490</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>IPv6-NBMA</kw>
            <kw>internet protocol</kw>
            <kw>Non-Broadcast Multiple Access</kw>
            <kw>routing</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]</p></abstract>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2491</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IPv6ATMNET</kw>
            <kw>internet protocol</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2492</errata-url>
        <doi>10.17487/RFC2492</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3593</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC2493</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trunkmib</wg_acronym>
        <doi>10.17487/RFC2494</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trunkmib</wg_acronym>
        <doi>10.17487/RFC2495</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>DS3-E3-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trunkmib</wg_acronym>
        <doi>10.17487/RFC2496</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-souvatzis-ipv6-arcnet-05</draft>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC1201</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2497</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPPM-MET</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC2678</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2498</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2499</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC2400</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2600</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2500</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>packet</kw>
            <kw>network</kw>
            <kw>hardwire</kw>
            <kw>wireless</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC2501</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>DIS</kw>
            <kw>distributed</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lsma</wg_acronym>
        <doi>10.17487/RFC2502</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2503</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>networks</kw>
            <kw>systems</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <is-also>
            <doc-id>FYI0034</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>ssh</wg_acronym>
        <doi>10.17487/RFC2504</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>agents</kw>
            <kw>sendmail</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2505</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>data</kw>
            <kw>formats</kw>
            <kw>vocabulary</kw>
            <kw>negotiation</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2506</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>tcp</kw>
            <kw>transmission control protocol</kw>
            <kw>bandwidth</kw>
        </keywords>
        <abstract><p>This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2507</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>UDP</kw>
            <kw>user datagram protocol</kw>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract><p>This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2508</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPCOM-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC3544</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2509</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>PKICMP</kw>
            <kw>pki</kw>
            <kw>security</kw>
            <kw>cryptographic</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-ipki3cmp-09</draft>
        <obsoleted-by>
            <doc-id>RFC4210</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC2510</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>X.509-CRMF</kw>
            <kw>crmf</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>authenticaion</kw>
        </keywords>
        <abstract><p>This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-crmf-01</draft>
        <obsoleted-by>
            <doc-id>RFC4211</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC2511</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>ATM</kw>
            <kw>autonomous transfer mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-atommib-atmacct-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC2512</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-atommib-acct-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC2513</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ATM-TC-OID</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-atommib-atm2TC-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC2514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2515</doc-id>
        <title>Definitions of Managed Objects for ATM Management</title>
        <author>
            <name>K. Tesink</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>87</page-count>
        <keywords>
            <kw>ATM-MIBMAN</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC2515</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <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><p>This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet.  This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2516</errata-url>
        <doi>10.17487/RFC2516</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>internet</kw>
            <kw>world</kw>
            <kw>wide</kw>
            <kw>web</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2517</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>WEBDAV</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>web</kw>
            <kw>content</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4918</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2518</errata-url>
        <doi>10.17487/RFC2518</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>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</p></abstract>
        <draft>draft-ietf-idr-aggregation-framework-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2519</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>NHRP-MNHCS</kw>
            <kw>next hop resolution protocol</kw>
            <kw>authentication</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ion-nhrp-mobile-nhc-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2520</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ICMP-SEC</kw>
            <kw>internet control message protocol</kw>
            <kw>ip</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-simpson-icmp-ipsec-fail-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2521</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>PHOTURIS-S</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
            <kw>ah</kw>
            <kw>esp</kw>
            <kw>encapsulating security payload</kw>
        </keywords>
        <abstract><p>This document defines the basic protocol mechanisms.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-simpson-photuris-18</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2522</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>PHOTURIS-E</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-simpson-photuris-schemes-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2523</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>EMSD</kw>
            <kw>wireless</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2524</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This memo catalogs a number of known TCP implementation problems.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpimpl-prob-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2525</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>routing</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-resv-anycast-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2526</errata-url>
        <doi>10.17487/RFC2526</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>pkix</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2527</errata-url>
        <doi>10.17487/RFC2527</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pkix-ipki-kea-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC2528</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>link-local</kw>
            <kw>link</kw>
            <kw>local</kw>
            <kw>addresses</kw>
            <kw>internet protocol</kw>
            <kw>ip</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-6over4-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2529</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DSN</kw>
            <kw>MDN</kw>
            <kw>message disposition notification</kw>
            <kw>delivery status notification</kw>
        </keywords>
        <abstract><p>This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fax-reporting-extensions-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2530</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>media</kw>
            <kw>features</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2531</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>mail</kw>
            <kw>user</kw>
            <kw>fax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-fax-eifax-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2532</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>message</kw>
            <kw>senders</kw>
            <kw>recipients</kw>
            <kw>file</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2533</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>data</kw>
            <kw>format</kw>
            <kw>vocabulary</kw>
            <kw>negotiation</kw>
            <kw>mechanisms</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-conneg-media-features-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2534</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2535</errata-url>
        <doi>10.17487/RFC2535</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DSA</kw>
            <kw>digital signature algorithm</kw>
            <kw>signatures</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnssec-dss-03</draft>
        <updated-by>
            <doc-id>RFC6944</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2536</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>message</kw>
            <kw>digest</kw>
            <kw>signatures</kw>
            <kw>cryptology</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnssec-rsa-01</draft>
        <obsoleted-by>
            <doc-id>RFC3110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2537</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SC-DNS</kw>
            <kw>cryptology</kw>
            <kw>authenticity</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnssec-certs-04</draft>
        <obsoleted-by>
            <doc-id>RFC4398</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2538</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHK-DNS</kw>
            <kw>Diffie-Hellman Keys</kw>
            <kw>Domain Name System</kw>
            <kw>cryptology</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>signatures</kw>
            <kw>digital</kw>
        </keywords>
        <abstract><p>A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnssec-dhk-03</draft>
        <updated-by>
            <doc-id>RFC6944</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2539</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNS-INFO</kw>
            <kw>Domain Name System</kw>
            <kw>security</kw>
            <kw>digital</kw>
            <kw>signatures</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnssec-ddi-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2540</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-dnssec-secops-02</draft>
        <obsoleted-by>
            <doc-id>RFC4641</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dnssec</wg_acronym>
        <doi>10.17487/RFC2541</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>real</kw>
            <kw>time</kw>
            <kw>session</kw>
            <kw>store</kw>
            <kw>forward</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-fax-goals-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2542</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>151</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC2543</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>testing</kw>
            <kw>performance</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1944</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6201</doc-id>
            <doc-id>RFC6815</doc-id>
            <doc-id>RFC9004</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2544</errata-url>
        <doi>10.17487/RFC2544</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BGP-4</kw>
            <kw>border gateway protocol</kw>
            <kw>idr</kw>
            <kw>Inter-Domain Routing</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2545</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2546</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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><p>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.</p></abstract>
        <obsoleted-by>
            <doc-id>RFC4364</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2547</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <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><p>This document describes the set of Microsoft vendor-specific RADIUS attributes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radius-ms-vsa-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2548</errata-url>
        <doi>10.17487/RFC2548</doi>
    </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>1</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>avian</kw>
            <kw>carrier</kw>
            <kw>april</kw>
            <kw>fools</kw>
            <kw>qos</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updates>
            <doc-id>RFC1149</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2549</errata-url>
        <doi>10.17487/RFC2549</doi>
    </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>1</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>years</kw>
            <kw>dates</kw>
            <kw>formats</kw>
            <kw>april</kw>
            <kw>fools</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2550</errata-url>
        <doi>10.17487/RFC2550</doi>
    </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>1</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>numerals</kw>
            <kw>protocols</kw>
            <kw>procedures</kw>
            <kw>april</kw>
            <kw>fools</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC2551</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>electronic</kw>
            <kw>systems</kw>
            <kw>products</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2552</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <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><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2553</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>layer</kw>
            <kw>sasl</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-myers-smtp-auth-12</draft>
        <obsoleted-by>
            <doc-id>RFC4954</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2555</doc-id>
        <title>30 Years of RFCs</title>
        <author>
            <name>RFC Editor, et al.</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>request</kw>
            <kw>for</kw>
            <kw>comments</kw>
            <kw>series</kw>
            <kw>documents</kw>
            <kw>publication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <updated-by>
            <doc-id>RFC8700</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2555</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>protocol</kw>
            <kw>ISO</kw>
            <kw>international</kw>
            <kw>organization for standardization</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bradner-1240.his-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2556</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>MHTML</kw>
            <kw>Hypertext Markup Language</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>multimedia</kw>
            <kw>uri</kw>
            <kw>uniform resource identifiers</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>mhtml</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2557</errata-url>
        <doi>10.17487/RFC2557</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC2558</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>IPKI</kw>
            <kw>Internet X.509 Public Key Infrastructure</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC2559</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>X.509</kw>
            <kw>digital</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-ocsp-07</draft>
        <obsoleted-by>
            <doc-id>RFC6960</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6277</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2560</errata-url>
        <doi>10.17487/RFC2560</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information base structure</kw>
            <kw>telnet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tn3270e-tn3270-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC2561</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>TN3270E-RT-MIB</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>structure</kw>
            <kw>telnet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tn3270e-rt-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC2562</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>internet</kw>
            <kw>address</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-autoconfig-04</draft>
        <updated-by>
            <doc-id>RFC8925</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC2563</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>APP-MIB</kw>
            <kw>application</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-applmib-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>applmib</wg_acronym>
        <doi>10.17487/RFC2564</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2565</errata-url>
        <doi>10.17487/RFC2565</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>173</page-count>
        <keywords>
            <kw>IPP-M-S</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>job</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC2566</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>IPP-DG</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipp-req-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC2567</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPP-RAT</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipp-rat-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC2568</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>IPP</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
            <kw>LPD</kw>
            <kw>line printer daemon</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipp-lpd-ipp-map-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC2569</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2570</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>ARCH-SNMP</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2571</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>MPD-SNMP</kw>
            <kw>processing</kw>
            <kw>models</kw>
            <kw>multiple</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2572</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2573</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>USM-SNMPV3</kw>
            <kw>message</kw>
            <kw>level</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2574</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>VACM-SNMP</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC2575</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network</kw>
            <kw>management protocol</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2576</errata-url>
        <doi>10.17487/RFC2576</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-ftpext-sec-consider-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ftpext</wg_acronym>
        <doi>10.17487/RFC2577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2578</doc-id>
        <title>Structure of Management Information Version 2 (SMIv2)</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Perkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>SMIv2</kw>
            <kw>Structure of Management Information Version 2</kw>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ops-smiv2-smi-01</draft>
        <obsoletes>
            <doc-id>RFC1902</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0058</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2579</doc-id>
        <title>Textual Conventions for SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Perkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>CONV-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>SMIv2</kw>
            <kw>Structure of Management Information Version 2 </kw>
            <kw>SNMPv2</kw>
            <kw>Simple Network Management Protocol Version 2</kw>
        </keywords>
        <abstract><p>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ops-smiv2-tc-01</draft>
        <obsoletes>
            <doc-id>RFC1903</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0058</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2579</errata-url>
        <doi>10.17487/RFC2579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2580</doc-id>
        <title>Conformance Statements for SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Perkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>CONF-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>SNMPv2</kw>
            <kw>Simple Network Management Protocol Version 2</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ops-smiv2-conf-01</draft>
        <obsoletes>
            <doc-id>RFC1904</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0058</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2580</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>TCP-CC</kw>
            <kw>Transmission Control Protocol</kw>
            <kw>Congestion Control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tcpimpl-cong-control-05</draft>
        <obsoletes>
            <doc-id>RFC2001</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5681</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3390</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2581</errata-url>
        <doi>10.17487/RFC2581</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2582</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>NHRP</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>IP</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-carlson-nhrp-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2583</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>APPN</kw>
            <kw> Advanced Peer-to-Peer Network</kw>
            <kw>HPR</kw>
            <kw>high performance routing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-snanau-hpripmib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>snanau</wg_acronym>
        <doi>10.17487/RFC2584</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>FTP</kw>
            <kw>file transfer protocol</kw>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>PKI</kw>
            <kw>Public Key Infrastructure</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-opp-ftp-http-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2585</errata-url>
        <doi>10.17487/RFC2585</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-alvestrand-audio-l16-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2586</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>pkix</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-ldapv2-schema-02</draft>
        <obsoleted-by>
            <doc-id>RFC4523</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC2587</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>security</kw>
            <kw>gateway</kw>
            <kw>traffic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mboned-mcast-firewall-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC2588</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>LDAPv3</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>request</kw>
            <kw>response</kw>
            <kw>operations</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-asid-ldapv3-dynamic-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <doi>10.17487/RFC2589</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet Protocol</kw>
            <kw>format</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract><p>This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ion-ipv6-fr-02</draft>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2590</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC2591</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC2592</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>smx</kw>
            <kw>language</kw>
            <kw>specific</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-schoenw-smx-00</draft>
        <obsoleted-by>
            <doc-id>RFC3179</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2593</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>WWW</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-applmib-wwwmib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>applmib</wg_acronym>
        <doi>10.17487/RFC2594</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ACAP</kw>
            <kw>application configuration access protocol</kw>
            <kw>POP3</kw>
            <kw>post office protocol</kw>
            <kw>IMAP</kw>
            <kw>internet message access protocol</kw>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-newman-tls-imappop-09</draft>
        <updated-by>
            <doc-id>RFC4616</doc-id>
            <doc-id>RFC7817</doc-id>
            <doc-id>RFC8314</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2595</errata-url>
        <doi>10.17487/RFC2595</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>servers</kw>
        </keywords>
        <abstract><p>This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <doi>10.17487/RFC2596</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PHB</kw>
            <kw>per-hop-behaviour</kw>
            <kw>DS</kw>
            <kw>differentiated services</kw>
            <kw>AF</kw>
            <kw>assured forwarding</kw>
        </keywords>
        <abstract><p>This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2597</errata-url>
        <doi>10.17487/RFC2597</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PHB</kw>
            <kw>per-hop-forwarding behavior</kw>
            <kw>DS</kw>
            <kw>differentiated services</kw>
            <kw>EF</kw>
            <kw>Expedited Forwarding</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2598</errata-url>
        <doi>10.17487/RFC2598</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2599</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2500</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2700</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2600</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ILMI</kw>
            <kw>integrated local management interface</kw>
            <kw>ATMARP</kw>
            <kw>asynchronous transfer mode address resolution protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ion-discov-atmarp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2601</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ILMI</kw>
            <kw>integrated local management interface</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>MARS</kw>
            <kw>Multicast Address Resolution Server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ion-discov-mars-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2602</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ILMI</kw>
            <kw>integrated local management interface</kw>
            <kw>NHRP</kw>
            <kw>next hop resolution protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ion-discov-nhrp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2603</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>over-the-air</kw>
            <kw>ota</kw>
            <kw>application</kw>
            <kw>configuration</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2604</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>network</kw>
            <kw>services</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-madman-dsa-mib-1</draft>
        <obsoletes>
            <doc-id>RFC1567</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC2605</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>private</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnsind-test-tlds-13</draft>
        <updated-by>
            <doc-id>RFC6761</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0032</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2606</errata-url>
        <doi>10.17487/RFC2606</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>network</kw>
            <kw>access</kw>
            <kw>server</kw>
            <kw>identifier</kw>
            <kw>radius</kw>
        </keywords>
        <abstract><p>This document describes how proxy chaining and policy implementation can be supported in roaming systems.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-roamops-auth-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>roamops</wg_acronym>
        <doi>10.17487/RFC2607</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>network</kw>
            <kw>services</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>svrloc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2608</errata-url>
        <doi>10.17487/RFC2608</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>service location protocol</kw>
            <kw>URL</kw>
            <kw>universal resource locator</kw>
        </keywords>
        <abstract><p>This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>svrloc</wg_acronym>
        <doi>10.17487/RFC2609</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-slp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC2610</doi>
    </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. Faltstrom</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>namespaces</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <doi>10.17487/RFC2611</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>security</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-adams-cast-256-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2612</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>smon</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-smon-07</draft>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC2613</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>slp</kw>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>This document describes standardized APIs for SLP in C and Java.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-svrloc-api-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>svrloc</wg_acronym>
        <doi>10.17487/RFC2614</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>SONET/SDH</kw>
            <kw>synchronous optical network</kw>
            <kw>synchronous digital hierarchy</kw>
        </keywords>
        <abstract><p>This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2615</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>176</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>World Wide Web</kw>
            <kw>WWW</kw>
            <kw>hypermedia</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-http-v11-spec-rev-06</draft>
        <obsoletes>
            <doc-id>RFC2068</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7230</doc-id>
            <doc-id>RFC7231</doc-id>
            <doc-id>RFC7232</doc-id>
            <doc-id>RFC7233</doc-id>
            <doc-id>RFC7234</doc-id>
            <doc-id>RFC7235</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2817</doc-id>
            <doc-id>RFC5785</doc-id>
            <doc-id>RFC6266</doc-id>
            <doc-id>RFC6585</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2616</errata-url>
        <doi>10.17487/RFC2616</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>hypertext transfer protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-http-authentication-03</draft>
        <obsoletes>
            <doc-id>RFC2069</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7235</doc-id>
            <doc-id>RFC7615</doc-id>
            <doc-id>RFC7616</doc-id>
            <doc-id>RFC7617</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2617</errata-url>
        <doi>10.17487/RFC2617</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>Remote Authentication Dial-In User Service</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radius-auth-clientmib-05</draft>
        <obsoleted-by>
            <doc-id>RFC4668</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2618</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <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><p>This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radius-auth-servmib-05</draft>
        <obsoleted-by>
            <doc-id>RFC4669</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2619</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>This memo defines a set of extensions which instrument RADIUS accounting client functions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radius-acc-clientmib-05</draft>
        <obsoleted-by>
            <doc-id>RFC4670</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2620</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <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><p>This memo defines a set of extensions which instrument RADIUS accounting server functions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radius-acc-servmib-05</draft>
        <obsoleted-by>
            <doc-id>RFC4671</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2621</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>RPSL</kw>
            <kw>Routing Policy Specification Language</kw>
            <kw>internet</kw>
            <kw>policy</kw>
            <kw>hierarchy</kw>
            <kw>network</kw>
            <kw>configuration</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rps-rpsl-v2-03</draft>
        <obsoletes>
            <doc-id>RFC2280</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4012</doc-id>
            <doc-id>RFC7909</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2622</errata-url>
        <doi>10.17487/RFC2622</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>NFSV4</kw>
            <kw>network file system version 4</kw>
            <kw>RPC</kw>
            <kw>remote procedure call</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-nfsv4-nfssec-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC2623</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nfsv4-designconsider-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC2624</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>ARP</kw>
            <kw>address resolution protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipfc-fibre-channel-06</draft>
        <obsoleted-by>
            <doc-id>RFC4338</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipfc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2625</errata-url>
        <doi>10.17487/RFC2625</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>275</page-count>
        <keywords>
            <kw>Y2K</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-2000-issue-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>2000</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2626</errata-url>
        <doi>10.17487/RFC2626</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>communication</kw>
            <kw>sessions</kw>
            <kw>net key</kw>
            <kw>rekey</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-wallner-key-arch-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2627</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>application</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document describes a simple Application Program Interface to cryptographic functions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-smyslov-crypto-api-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2628</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>internet-drafts</kw>
            <kw>extensible markup</kw>
            <kw>language</kw>
            <kw>source format</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-mrose-writing-rfcs-02</draft>
        <obsoleted-by>
            <doc-id>RFC7749</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2629</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>key</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>This document describes the Cryptographic Message Syntax.  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2630</errata-url>
        <doi>10.17487/RFC2630</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Diffie-Hellman</kw>
            <kw>encryption</kw>
            <kw>management</kw>
            <kw>certificate</kw>
        </keywords>
        <abstract><p>This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-x942-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2631</errata-url>
        <doi>10.17487/RFC2631</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>secure</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC2632</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2633</errata-url>
        <doi>10.17487/RFC2633</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>S/MIME</kw>
            <kw>secure</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-ess-12</draft>
        <updated-by>
            <doc-id>RFC5035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2634</errata-url>
        <doi>10.17487/RFC2634</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>email</kw>
            <kw>users</kw>
            <kw>administrators</kw>
            <kw>managers</kw>
        </keywords>
        <abstract><p>This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community.  This memo provides information for the Internet community.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>run</wg_acronym>
        <doi>10.17487/RFC2635</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>over-the-air</kw>
            <kw>ota</kw>
            <kw>application</kw>
            <kw>configuration</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2604</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2636</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2637</doc-id>
        <title>Point-to-Point Tunneling Protocol (PPTP)</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>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>tunnel</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pppext-pptp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2637</errata-url>
        <doi>10.17487/RFC2637</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>header</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>This document presents a differentiated services architecture for the internet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-nichols-diff-svc-arch-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2638</errata-url>
        <doi>10.17487/RFC2638</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>IPP</kw>
            <kw>client</kw>
            <kw>object</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC2639</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>ftp</kw>
            <kw>File Transfer Protocol</kw>
            <kw>character sets</kw>
            <kw>languages</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ftpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2640</errata-url>
        <doi>10.17487/RFC2640</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ISMP</kw>
            <kw>inter switch</kw>
            <kw>message</kw>
            <kw>protocol</kw>
            <kw>switches</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2641</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <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><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2642</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>SFVLAN</kw>
            <kw>switching</kw>
            <kw>data packets</kw>
            <kw>vitrual LANs</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC2643</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>smurf</kw>
            <kw>amplifiers</kw>
            <kw>denial of service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2644</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ODMR-SMTP</kw>
            <kw>On-Demand Mail Relay</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-gellens-on-demand-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2645</errata-url>
        <doi>10.17487/RFC2645</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>media type</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2646</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>routers</kw>
            <kw>switches</kw>
            <kw>measurement</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-bmwg-secperf-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC2647</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-urn-ietf-09</draft>
        <updated-by>
            <doc-id>RFC6924</doc-id>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2648</errata-url>
        <doi>10.17487/RFC2648</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ldapext-sigops-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <doi>10.17487/RFC2649</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>routing policy</kw>
            <kw>specification language</kw>
            <kw>IRR</kw>
            <kw>internet routing</kw>
            <kw>registry</kw>
            <kw>configurations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rps-appl-rpsl-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <doi>10.17487/RFC2650</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>CIP</kw>
            <kw>Common Indexing Protocol</kw>
            <kw>query</kw>
            <kw>routing</kw>
            <kw>database</kw>
            <kw>servers</kw>
        </keywords>
        <abstract><p>This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-find-cip-arch-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <doi>10.17487/RFC2651</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>database</kw>
            <kw>CIP</kw>
            <kw>Common Indexing Protocol</kw>
        </keywords>
        <abstract><p>This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-find-cip-mime-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <doi>10.17487/RFC2652</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CIP</kw>
            <kw>common indexing protocol</kw>
            <kw>message</kw>
            <kw>formats</kw>
        </keywords>
        <abstract><p>This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-find-cip-trans-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <doi>10.17487/RFC2653</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>CIP</kw>
            <kw>Common Indexing Protocol</kw>
            <kw>information</kw>
            <kw>servers</kw>
            <kw>database</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-find-cip-tagged-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <doi>10.17487/RFC2654</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>CIP</kw>
            <kw>SOIF</kw>
            <kw>summary object interchange format</kw>
            <kw>common indexing protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-find-cip-soif-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2655</errata-url>
        <doi>10.17487/RFC2655</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SOIF</kw>
            <kw>summary object interchange format</kw>
            <kw>stream</kw>
        </keywords>
        <abstract><p>The registration procedure described in this document is specific to SOIF template types.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-find-soif-registry-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2656</errata-url>
        <doi>10.17487/RFC2656</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>LDAPv2</kw>
            <kw>lightweight directory access protocol version 2</kw>
            <kw>CIP</kw>
            <kw>common indexing protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-find-cip-ldapv2-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>find</wg_acronym>
        <doi>10.17487/RFC2657</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>packet</kw>
            <kw>end-to-end</kw>
        </keywords>
        <abstract><p>This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mckay-qcelp-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2658</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>HTML</kw>
            <kw>hyper-text markup language</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract><p>This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-wts-shtml-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>wts</wg_acronym>
        <doi>10.17487/RFC2659</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>WWW</kw>
            <kw>world wide web</kw>
            <kw>http</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.</p><p> The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.</p></abstract>
        <draft>draft-ietf-wts-shttp-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>wts</wg_acronym>
        <doi>10.17487/RFC2660</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer Two Tunneling Protocol</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pppext-l2tp-16</draft>
        <updated-by>
            <doc-id>RFC9601</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2661</errata-url>
        <doi>10.17487/RFC2661</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>115</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>ADSL</kw>
            <kw>Asymmetric Bit-Rate DSL</kw>
        </keywords>
        <abstract><p>This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-adslmib-adsllinemib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2662</errata-url>
        <doi>10.17487/RFC2662</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>network address</kw>
            <kw>translator</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-terminology-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2663</errata-url>
        <doi>10.17487/RFC2663</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>documentation</kw>
            <kw>help</kw>
            <kw>information</kw>
            <kw>FAQ</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>uswg</wg_acronym>
        <doi>10.17487/RFC2664</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC2665</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-hubmib-ether-chipsets-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC2666</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ifmib-tunnel-mib-06</draft>
        <obsoleted-by>
            <doc-id>RFC4087</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC2667</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>MAU-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC2668</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipcdn-cable-device-mib-08</draft>
        <obsoleted-by>
            <doc-id>RFC4639</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC2669</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipcdn-rf-interface-mib-07</draft>
        <obsoleted-by>
            <doc-id>RFC4546</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC2670</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>EDNS0</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
            <kw>resource records</kw>
            <kw>opt</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsind-edns0-02</draft>
        <obsoleted-by>
            <doc-id>RFC6891</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <doi>10.17487/RFC2671</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>dname</kw>
            <kw>RR</kw>
            <kw>resource records</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsind-dname-03</draft>
        <obsoleted-by>
            <doc-id>RFC6672</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4592</doc-id>
            <doc-id>RFC6604</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <doi>10.17487/RFC2672</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsind-binary-labels-05</draft>
        <obsoleted-by>
            <doc-id>RFC6891</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3363</doc-id>
            <doc-id>RFC3364</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsind</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2673</errata-url>
        <doi>10.17487/RFC2673</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bridge-bridgemib-06</draft>
        <obsoleted-by>
            <doc-id>RFC4363</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <doi>10.17487/RFC2674</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>packet</kw>
            <kw>payload</kw>
            <kw>link</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2675</errata-url>
        <doi>10.17487/RFC2675</doi>
    </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. Kamat</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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>QoS</kw>
            <kw>quality of service</kw>
            <kw>OSPF</kw>
            <kw>open shortest path first</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-guerin-qos-routing-ospf-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2676</errata-url>
        <doi>10.17487/RFC2676</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>NHRP-MIB</kw>
            <kw>Next Hop Resolution Protocol</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>NBMA</kw>
            <kw>Non-Broadcast</kw>
            <kw>Multi-Access</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ion-nhrp-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2677</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPPM-MET</kw>
            <kw>internet protocol performance metrics</kw>
        </keywords>
        <abstract><p>This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC2498</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2678</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>internet protocol performance metrics</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-delay-07</draft>
        <obsoleted-by>
            <doc-id>RFC7679</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2679</errata-url>
        <doi>10.17487/RFC2679</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>internet protocol performance metrics</kw>
        </keywords>
        <abstract><p>This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-loss-07</draft>
        <obsoleted-by>
            <doc-id>RFC7680</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2680</errata-url>
        <doi>10.17487/RFC2680</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>internet protocol performance metrics</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-rt-delay-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2681</errata-url>
        <doi>10.17487/RFC2681</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer mode</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-widjaja-mpls-vc-merge-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2682</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>clients</kw>
            <kw>servers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-leiba-imap-implement-guide-10</draft>
        <updated-by>
            <doc-id>RFC7162</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2683</errata-url>
        <doi>10.17487/RFC2683</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>multiplexing</kw>
        </keywords>
        <abstract><p>This memo replaces RFC 1483.  It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2684</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>VPNI</kw>
            <kw>Virtual Private Networks Identifier</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ion-vpn-id-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2685</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-issll-isslow-mcml-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2686</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>encapsulation</kw>
            <kw>HDLC</kw>
            <kw>high-level data link control</kw>
        </keywords>
        <abstract><p>This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-issll-isslow-rtf-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2687</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>controlled</kw>
            <kw>load</kw>
            <kw>guaranteed</kw>
            <kw>services</kw>
        </keywords>
        <abstract><p>This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-issll-isslow-svcmap-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2688</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>synchronous</kw>
            <kw>real-time</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-issll-isslow-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2689</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>pso</kw>
            <kw>memorandum of understanding</kw>
            <kw>internet</kw>
            <kw>corporation for assigned names and numbers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-poisson-mou-pso-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC2690</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>mou</kw>
            <kw>pso</kw>
            <kw>internet</kw>
            <kw>corporation for assigned names and numbers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-poisson-pso-mou-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC2691</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SPKI</kw>
            <kw>simple public key infrastructure</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-spki-cert-req-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>spki</wg_acronym>
        <doi>10.17487/RFC2692</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>SPKI</kw>
            <kw>simple public key infrastructure</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-spki-cert-theory-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>spki</wg_acronym>
        <doi>10.17487/RFC2693</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>domain name</kw>
            <kw>system</kw>
            <kw>NATs</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-dns-alg-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2694</errata-url>
        <doi>10.17487/RFC2694</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>remote procedure</kw>
            <kw>call</kw>
            <kw>open network</kw>
            <kw>computing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-oncrpc-auth-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>oncrpc</wg_acronym>
        <doi>10.17487/RFC2695</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>This document describes an LDAPv3 control extension for simple paging of search results.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-asid-ldapv3-simplepaged-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2696</errata-url>
        <doi>10.17487/RFC2696</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>srtcm</kw>
            <kw>stream</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>packet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-heinanen-diffserv-srtcm-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2697</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>trTCM</kw>
            <kw>stream</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>packet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-heinanen-diffserv-trtcm-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2698</errata-url>
        <doi>10.17487/RFC2698</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2699</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2600</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2800</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2700</errata-url>
        <doi>10.17487/RFC2700</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>point-to-point</kw>
            <kw>POP</kw>
            <kw>presence</kw>
            <kw>RAS</kw>
            <kw>remote access</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>This document specifies a standard way for Multi-link PPP to operate across multiple nodes.  This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2701</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>multiprotocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-traffic-eng-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2702</errata-url>
        <doi>10.17487/RFC2702</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>feature</kw>
            <kw>resource</kw>
            <kw>media</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-conneg-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2703</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>security</kw>
            <kw>policy maker</kw>
            <kw>system</kw>
            <kw>credentials</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-blaze-ietf-trustmgt-keynote-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2704</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>134</page-count>
        <keywords>
            <kw>voice</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2705</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>electronic</kw>
            <kw>commerce</kw>
            <kw>modeling</kw>
            <kw>language</kw>
            <kw>merchant</kw>
            <kw>site. web</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2706</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>114</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-printmib-job-monitor-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>printmib</wg_acronym>
        <doi>10.17487/RFC2707</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-printmib-job-protomap-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>printmib</wg_acronym>
        <doi>10.17487/RFC2708</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>network address</kw>
            <kw>translator</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-security-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <doi>10.17487/RFC2709</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>MLD-IPv6</kw>
            <kw>Multicast Listener Discovery</kw>
            <kw>internet protocol</kw>
            <kw>router</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-mld-02</draft>
        <updated-by>
            <doc-id>RFC3590</doc-id>
            <doc-id>RFC3810</doc-id>
            <doc-id>RFC9777</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2710</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>datagram</kw>
            <kw>router</kw>
            <kw>hop-by-hop</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-ipv6router-alert-06</draft>
        <updated-by>
            <doc-id>RFC6398</doc-id>
            <doc-id>RFC9805</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2711</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>Transport Layer Security</kw>
            <kw>authentication</kw>
            <kw>cryptography</kw>
        </keywords>
        <abstract><p>This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-kerb-cipher-suites-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2712</errata-url>
        <doi>10.17487/RFC2712</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This document defines the schema for representing Java(tm) objects in an LDAP directory.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ryan-java-schema-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2713</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This document defines the schema for representing CORBA object references in an LDAP directory.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ryan-corba-schema-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2714</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>border</kw>
            <kw>router</kw>
            <kw>MBRs</kw>
            <kw>autonomous</kw>
        </keywords>
        <abstract><p>The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-thaler-multicast-interop-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2715</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>EAP</kw>
            <kw>Extensible Authentication Protocol</kw>
            <kw>LCP</kw>
            <kw>link control protocol</kw>
            <kw>CCP</kw>
            <kw>compression control protocol</kw>
            <kw>TLS</kw>
            <kw>transport level security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pppext-eaptls-06</draft>
        <obsoleted-by>
            <doc-id>RFC5216</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2716</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-urlreg-procedures-08</draft>
        <obsoleted-by>
            <doc-id>RFC4395</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urlreg</wg_acronym>
        <doi>10.17487/RFC2717</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>This document provides guidelines for the definition of new URL schemes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-urlreg-guide-05</draft>
        <obsoleted-by>
            <doc-id>RFC4395</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urlreg</wg_acronym>
        <doi>10.17487/RFC2718</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Internet Protocol</kw>
            <kw>gateway</kw>
            <kw>media</kw>
            <kw>circuit</kw>
        </keywords>
        <abstract><p>This document defines an architecture framework and functional requirements for transport of signaling information over IP.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sigtran-framework-arch-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC2719</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2720</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>traffic flow</kw>
            <kw>measurement</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rtfm-applicability-statement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2721</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>network</kw>
            <kw>meters</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rtfm-architecture-08</draft>
        <obsoletes>
            <doc-id>RFC2063</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2722</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>ruleset</kw>
            <kw>RTFM</kw>
            <kw>real-time</kw>
            <kw>network</kw>
            <kw>measurement</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rtfm-ruleset-language-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2723</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RTFM</kw>
            <kw>real-time traffic flow measurement</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rtfm-new-traffic-flow-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rtfm</wg_acronym>
        <doi>10.17487/RFC2724</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>RPSL</kw>
            <kw>Routing Policy Specification Language</kw>
            <kw>system</kw>
            <kw>security</kw>
            <kw>database</kw>
            <kw>registry</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <doi>10.17487/RFC2725</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PGP</kw>
            <kw>pretty good privacy</kw>
            <kw>security</kw>
            <kw>digital</kw>
            <kw>signatures</kw>
        </keywords>
        <abstract><p>This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rps-dbsec-pgp-authent-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <doi>10.17487/RFC2726</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>Engineering</kw>
            <kw>Steering</kw>
            <kw>Group</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC2727</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>IPVBI</kw>
            <kw>IP Over the Vertical Blanking Interval of Television Signal</kw>
        </keywords>
        <abstract><p>This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipvbi-nabts-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipvbi</wg_acronym>
        <doi>10.17487/RFC2728</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>LSMA</kw>
            <kw>dynamic</kw>
            <kw>protocol</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-lsma-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lsma</wg_acronym>
        <doi>10.17487/RFC2729</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>MADCAP</kw>
            <kw>Multicast Address Dynamic Client Allocation Protocol</kw>
            <kw>server</kw>
            <kw>scope</kw>
            <kw>zone</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-malloc-madcap-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC2730</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>hypertext</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>xml</kw>
            <kw>extensible</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-kunze-dchtml-02</draft>
        <obsoleted-by>
            <doc-id>RFC5791</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2731</errata-url>
        <doi>10.17487/RFC2731</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2732</errata-url>
        <doi>10.17487/RFC2732</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>Forward Error Correction</kw>
            <kw>RTP</kw>
            <kw>real-time protocol</kw>
            <kw>stream</kw>
        </keywords>
        <abstract><p>This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-fec-08</draft>
        <obsoleted-by>
            <doc-id>RFC5109</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2733</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>datagrams</kw>
            <kw>packet</kw>
            <kw>encapsulation</kw>
            <kw>ARP</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>multicast</kw>
            <kw>IEEE</kw>
            <kw>Institute of Electrical and Electronics Engineers</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ip1394-ipv4-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ip1394</wg_acronym>
        <doi>10.17487/RFC2734</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>NHRP</kw>
            <kw>next hop resolution protocol</kw>
            <kw>VPN</kw>
            <kw>Virtual Private Network</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ion-nhrp-vpn-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2735</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-avt-rtp-format-guidelines-04</draft>
        <updated-by>
            <doc-id>RFC8088</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0036</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2736</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>SNMP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-entmib-v2-06</draft>
        <obsoletes>
            <doc-id>RFC2037</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4133</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>entmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2737</errata-url>
        <doi>10.17487/RFC2737</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>Forward Error Correction</kw>
            <kw>real-time protocol</kw>
            <kw>stream</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2738</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>calendar</kw>
        </keywords>
        <abstract><p>This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-calsch-locating-03</draft>
        <updated-by>
            <doc-id>RFC6350</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2739</errata-url>
        <doi>10.17487/RFC2739</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>OSPF</kw>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-ospfv6-08</draft>
        <obsoleted-by>
            <doc-id>RFC5340</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2740</errata-url>
        <doi>10.17487/RFC2740</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>agentx</wg_acronym>
        <doi>10.17487/RFC2741</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-agentx-mib-05</draft>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>agentx</wg_acronym>
        <doi>10.17487/RFC2742</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>Generic Security Service Application Program Interface</kw>
            <kw>authentication</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract><p>This memo obsoletes [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-cat-rfc2078bis-08</draft>
        <obsoletes>
            <doc-id>RFC2078</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5554</doc-id>
            <doc-id>RFC5896</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2743</errata-url>
        <doi>10.17487/RFC2743</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>Generic Security Service Application Program Interface</kw>
            <kw>cryptology</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-cat-gssv2-cbind-09</draft>
        <obsoletes>
            <doc-id>RFC1509</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5896</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2744</errata-url>
        <doi>10.17487/RFC2744</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>network</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rsvp-diagnostic-msgs-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC2745</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rsvp-tunnel-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC2746</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2747</errata-url>
        <doi>10.17487/RFC2747</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>COPS</kw>
            <kw>Common Open Policy Service</kw>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract><p>This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rap-cops-08</draft>
        <updated-by>
            <doc-id>RFC4261</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2748</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>COPS</kw>
            <kw>common open policy service</kw>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rap-cops-rsvp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2749</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>admission</kw>
        </keywords>
        <abstract><p>This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2750</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <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><p>This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2751</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>admission</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2752</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rap-framework-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2753</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-rps-iana-02</draft>
        <obsoleted-by>
            <doc-id>RFC6254</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <doi>10.17487/RFC2754</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>QOS</kw>
            <kw>resource reservation</kw>
            <kw>protocol</kw>
            <kw>quality of service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-chiu-network-wnfs-sec-nego-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2755</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>HTCP</kw>
            <kw>Hyper Text Cashing Protocol</kw>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>caches</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-vixie-htcp-proto-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2756</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-montenegro-pilc-ltn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2757</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>SLAs</kw>
            <kw>Service Level Agreements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-white-slapm-mib-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2758</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>challenge</kw>
            <kw>handshake</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pppext-mschap-v2-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2759</errata-url>
        <doi>10.17487/RFC2759</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>bandwidth</kw>
            <kw>network</kw>
            <kw>links</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tcpsat-res-issues-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpsat</wg_acronym>
        <doi>10.17487/RFC2760</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>performance</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-atm-term-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC2761</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-avt-rtpsample-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2762</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>intermediate</kw>
            <kw>system</kw>
            <kw>routers</kw>
            <kw>TLV</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-dyname-02</draft>
        <obsoleted-by>
            <doc-id>RFC5301</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2763</errata-url>
        <doi>10.17487/RFC2763</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>VPN</kw>
            <kw>internet protocol</kw>
            <kw>backbone</kw>
        </keywords>
        <abstract><p>This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-gleeson-vpn-framework-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2764</errata-url>
        <doi>10.17487/RFC2764</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>SIIT</kw>
            <kw>Stateless IP/ICMP Translation Algorithm</kw>
            <kw>internet protocol</kw>
            <kw>internet control message protocol</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ngtrans-siit-08</draft>
        <obsoleted-by>
            <doc-id>RFC6145</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2765</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>NAT-PT</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ngtrans-natpt-07</draft>
        <obsoleted-by>
            <doc-id>RFC4966</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3152</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2766</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ngtrans-bis-00</draft>
        <obsoleted-by>
            <doc-id>RFC6535</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2767</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>protocols</kw>
            <kw>internet</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-aiken-middleware-reqndef-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2768</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>RPSL</kw>
            <kw>Routing Policy Specification Language</kw>
            <kw>Routing Policy System Security</kw>
            <kw>database</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rps-dist-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rps</wg_acronym>
        <doi>10.17487/RFC2769</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>allocation</kw>
            <kw>global</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC2770</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>application</kw>
            <kw>programming</kw>
            <kw>interfaces</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-malloc-api-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC2771</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2772</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>KEA</kw>
            <kw>key exchange algorithm</kw>
            <kw>SKIPJACK</kw>
            <kw>symmetric</kw>
        </keywords>
        <abstract><p>This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October</p></abstract>
        <draft>draft-ietf-cat-ftpkeasj-01</draft>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2773</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>hyper-text</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>A wide range of applications have proposed various extensions of the HTTP protocol.  Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms.  These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns.  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.  The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.</p></abstract>
        <draft>draft-frystyk-http-extensions-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2774</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>end-to-end</kw>
            <kw>network layer</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract><p>This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.</p></abstract>
        <draft>draft-carpenter-transparency-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2775</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>MZAP</kw>
            <kw>Multicast-Scope Zone Announcement Protocol</kw>
            <kw>packets</kw>
            <kw>addresses</kw>
            <kw>service</kw>
            <kw>location</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mboned-mzap-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC2776</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task Force</kw>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-eastlake-selection-04</draft>
        <obsoleted-by>
            <doc-id>RFC3797</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC2777</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>service users</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-impp-model-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <doi>10.17487/RFC2778</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail extensions</kw>
            <kw>service</kw>
            <kw>users</kw>
        </keywords>
        <abstract><p>This document defines a minimal set of requirements that IMPP must meet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-impp-reqts-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <doi>10.17487/RFC2779</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bradner-iana-allocation-05</draft>
        <updated-by>
            <doc-id>RFC4443</doc-id>
            <doc-id>RFC5237</doc-id>
            <doc-id>RFC5771</doc-id>
            <doc-id>RFC6335</doc-id>
            <doc-id>RFC7045</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0037</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2780</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>unicode</kw>
            <kw>character</kw>
            <kw>data</kw>
            <kw>code</kw>
            <kw>point</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hoffman-utf16-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2781</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNS-SRV</kw>
            <kw>domain name system</kw>
            <kw>service</kw>
            <kw>RR</kw>
            <kw>resource record</kw>
        </keywords>
        <abstract><p>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsind-rfc2052bis-05</draft>
        <obsoletes>
            <doc-id>RFC2052</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6335</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2782</errata-url>
        <doi>10.17487/RFC2782</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-mogul-pps-api-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2783</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>GRE</kw>
            <kw>Generic Routing Encapsulation</kw>
            <kw>packet</kw>
            <kw>size</kw>
            <kw>payload</kw>
        </keywords>
        <abstract><p>This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-meyer-gre-update-03</draft>
        <updated-by>
            <doc-id>RFC2890</doc-id>
            <doc-id>RFC9601</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2784</errata-url>
        <doi>10.17487/RFC2784</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>security</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-small-subgroup-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC2785</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>USM</kw>
            <kw>user-based security model</kw>
            <kw>Diffie-Hellman</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-stjohns-snmpv3-dhkeychange-mib-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2786</errata-url>
        <doi>10.17487/RFC2786</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>VRRP</kw>
            <kw>Virtual Router Redundancy Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-vrrp-mib-09</draft>
        <obsoleted-by>
            <doc-id>RFC6527</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>vrrp</wg_acronym>
        <doi>10.17487/RFC2787</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC2788</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>mail</kw>
            <kw>monitoring</kw>
        </keywords>
        <abstract><p>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 [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>madman</wg_acronym>
        <doi>10.17487/RFC2789</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>host</kw>
            <kw>resources</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ops-hostmib-01</draft>
        <obsoletes>
            <doc-id>RFC1514</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2790</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>network</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-yu-routing-scaling-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC2791</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>cryptology</kw>
            <kw>digial</kw>
            <kw>signatures</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-angelos-keynote-dsa-rsa-encoding-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2792</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>applications</kw>
            <kw>video</kw>
            <kw>audio</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-text-05</draft>
        <obsoleted-by>
            <doc-id>RFC4103</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2793</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>NAI</kw>
            <kw>Network Access Identifier</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC2794</doi>
    </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>1</day>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>control</kw>
            <kw>packet</kw>
            <kw>client</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-christey-imps-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC2795</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idr-route-reflect-v2-03</draft>
        <obsoleted-by>
            <doc-id>RFC4456</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1966</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2796</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>CMC</kw>
            <kw>certificate management</kw>
            <kw>protocol</kw>
            <kw>cryptology</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-cmc-05</draft>
        <obsoleted-by>
            <doc-id>RFC5272</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2797</errata-url>
        <doi>10.17487/RFC2797</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>directory services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-smith-ldap-inetorgperson-03</draft>
        <updated-by>
            <doc-id>RFC3698</doc-id>
            <doc-id>RFC4519</doc-id>
            <doc-id>RFC4524</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2798</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2799</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2700</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2900</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2800</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>290</page-count>
        <keywords>
            <kw>commerce</kw>
            <kw>payment</kw>
            <kw>system</kw>
            <kw>merchant</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-trade-iotp-v1.0-protocol-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC2801</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-trade-iotp-v1.0-dsig-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2802</errata-url>
        <doi>10.17487/RFC2802</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>secruity</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-trade-hiroshi-dom-hash-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC2803</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-raven-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2804</errata-url>
        <doi>10.17487/RFC2804</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>MG</kw>
            <kw>mapping</kw>
            <kw>transcoding</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-megaco-reqs-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>megaco</wg_acronym>
        <doi>10.17487/RFC2805</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>schemes</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2806</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>digital</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-xmldsig-requirements-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>xmldsig</wg_acronym>
        <doi>10.17487/RFC2807</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>layer</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-nystrom-securid-sasl-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2808</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-radius-tunnel-imp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <doi>10.17487/RFC2809</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-kalt-irc-arch-00</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2810</errata-url>
        <doi>10.17487/RFC2810</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract><p>This document specifies how channels, their characteristics and properties are managed by IRC servers.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kalt-irc-chan-01</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC2811</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-kalt-irc-client-03</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2812</errata-url>
        <doi>10.17487/RFC2812</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract><p>This document defines the protocol used by servers to talk to each other.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kalt-irc-server-02</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2813</errata-url>
        <doi>10.17487/RFC2813</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>SBM</kw>
            <kw>Subnet Bandwidth Manager</kw>
            <kw>LAN</kw>
            <kw>local area network</kw>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-issll-is802-sbm-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2814</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>LAN</kw>
            <kw>local area network</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-issll-is802-svc-mapping-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2815</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>LAN</kw>
            <kw>local area</kw>
            <kw>network</kw>
            <kw>parameter</kw>
            <kw>switches</kw>
        </keywords>
        <abstract><p>This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-issll-is802-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2816</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>TLS</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tls-http-upgrade-05</draft>
        <updates>
            <doc-id>RFC2616</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7230</doc-id>
            <doc-id>RFC7231</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2817</errata-url>
        <doi>10.17487/RFC2817</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tls-https-04</draft>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5785</doc-id>
            <doc-id>RFC7230</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2818</errata-url>
        <doi>10.17487/RFC2818</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>98</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>Remote Monitoring</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-rmonfull-02</draft>
        <obsoletes>
            <doc-id>RFC1757</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0059</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2819</errata-url>
        <doi>10.17487/RFC2819</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ldapext-acl-reqts-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2820</errata-url>
        <doi>10.17487/RFC2820</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>Simple Mail Transfer Protocol</kw>
        </keywords>
        <abstract><p>This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-drums-smtpupd-13</draft>
        <obsoletes>
            <doc-id>RFC0821</doc-id>
            <doc-id>RFC0974</doc-id>
            <doc-id>RFC1869</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5321</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5336</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>drums</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2821</errata-url>
        <doi>10.17487/RFC2821</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>MAIL</kw>
        </keywords>
        <abstract><p>This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-drums-msg-fmt-09</draft>
        <obsoletes>
            <doc-id>RFC0822</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5322</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5335</doc-id>
            <doc-id>RFC5336</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>drums</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2822</errata-url>
        <doi>10.17487/RFC2822</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>PPP-SDL</kw>
            <kw>point-to-point protocol</kw>
            <kw>Simple Data Link</kw>
            <kw>SONET</kw>
            <kw>synchronous optical network</kw>
            <kw>SDH</kw>
            <kw>synchronous digital hierarchy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pppext-sdl-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2823</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>CPL-F</kw>
            <kw>telephony</kw>
            <kw>signalling</kw>
            <kw>network</kw>
            <kw>devices</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-iptel-cpl-framework-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC2824</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>character sets</kw>
            <kw>e-commerce</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-i18n-dns-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2825</errata-url>
        <doi>10.17487/RFC2825</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Internet Architecture Board</kw>
            <kw>domain name</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-unique-dns-root-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2826</errata-url>
        <doi>10.17487/RFC2826</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>IP</kw>
            <kw>Internet Protocol</kw>
            <kw>DOS </kw>
            <kw>Denial of Service</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2827</errata-url>
        <doi>10.17487/RFC2827</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>212</page-count>
        <keywords>
            <kw>information</kw>
            <kw>system</kw>
            <kw>ISD</kw>
            <kw>internet</kw>
            <kw>standard documents</kw>
        </keywords>
        <abstract><p>This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shirey-security-glossary-02</draft>
        <obsoleted-by>
            <doc-id>RFC4949</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2828</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapext-authmeth-04</draft>
        <obsoleted-by>
            <doc-id>RFC4513</doc-id>
            <doc-id>RFC4510</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <doi>10.17487/RFC2829</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapext-ldapv3-tls-06</draft>
        <obsoleted-by>
            <doc-id>RFC4511</doc-id>
            <doc-id>RFC4513</doc-id>
            <doc-id>RFC4510</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <doi>10.17487/RFC2830</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>http</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>SASL</kw>
            <kw>Simple Authentication and Security Layer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-leach-digest-sasl-05</draft>
        <obsoleted-by>
            <doc-id>RFC6331</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2831</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-hollenbeck-rrp-01</draft>
        <updated-by>
            <doc-id>RFC3632</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2832</errata-url>
        <doi>10.17487/RFC2832</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time application protocol</kw>
            <kw>DTMF</kw>
            <kw>dual-tone multifrequency</kw>
        </keywords>
        <abstract><p>This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-tones-07</draft>
        <obsoleted-by>
            <doc-id>RFC4733</doc-id>
            <doc-id>RFC4734</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2833</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>ARP</kw>
            <kw>address resolution protocol</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>high-performance parallel interface</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-pittet-hippiarp-05</draft>
        <obsoletes>
            <doc-id>RFC1374</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2834</errata-url>
        <doi>10.17487/RFC2834</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>GSN</kw>
            <kw>Gigabyte System Network</kw>
            <kw>ARP</kw>
            <kw>address resolution protocol</kw>
            <kw>internet</kw>
            <kw>HIPPI</kw>
            <kw>high-performance parallel interface</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-pittet-gsnlan-04</draft>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2835</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PHB</kw>
            <kw>differentiated</kw>
            <kw>services</kw>
            <kw>codepoint</kw>
            <kw>DSCP</kw>
        </keywords>
        <abstract><p>This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC2836</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipfc</wg_acronym>
        <doi>10.17487/RFC2837</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>URI</kw>
            <kw>TV</kw>
            <kw>WWW</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zigmond-tv-url-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2838</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>management</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-columbia-kermit-service-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2839</errata-url>
        <doi>10.17487/RFC2839</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>file transfer</kw>
            <kw>management</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-altman-telnet-kermit-server-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2840</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IP-MAC</kw>
            <kw>encryption</kw>
            <kw>SHA1</kw>
            <kw>secure hash algorithm</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-simpson-ah-sha-kdp-00</draft>
        <obsoletes>
            <doc-id>RFC1852</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2841</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2842</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PNNI augmented Routing</kw>
            <kw>ATM</kw>
            <kw>asynchronous</kw>
            <kw>transfer mode</kw>
        </keywords>
        <abstract><p>The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ion-proxypar-arch-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ion</wg_acronym>
        <doi>10.17487/RFC2843</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>PNNI</kw>
            <kw>Augmented Routing</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>OSPF</kw>
            <kw>open shortest-path first</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ospf-atm-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC2844</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>transaction</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsext-tsig-00</draft>
        <obsoleted-by>
            <doc-id>RFC8945</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3645</doc-id>
            <doc-id>RFC4635</doc-id>
            <doc-id>RFC6895</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC2845</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>GSTN</kw>
            <kw>global switched telephone network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2846</errata-url>
        <doi>10.17487/RFC2846</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>LIPKEY</kw>
            <kw>Low Infrastructure Public Key</kw>
            <kw>SPKM</kw>
            <kw>Simple Public Key Mechanism</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-cat-lipkey-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2847</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>PINT</kw>
            <kw>PSTN/Internet Interworking</kw>
            <kw>SIP</kw>
            <kw>session initiation protocol</kw>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pint-protocol-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>trans</wg_acronym>
        <doi>10.17487/RFC2848</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>LDIF</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>Data Interchange Format</kw>
            <kw>file</kw>
        </keywords>
        <abstract><p>This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-good-ldap-ldif-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2849</errata-url>
        <doi>10.17487/RFC2849</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ISOC</kw>
            <kw>Internet Society</kw>
            <kw>IETF</kw>
            <kw>IRTF</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-rfc1601bis-04</draft>
        <obsoletes>
            <doc-id>RFC1601</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9283</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0039</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2850</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>layer</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>inet</kw>
            <kw>address mib</kw>
        </keywords>
        <abstract><p>This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2851</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-newman-deliver-03</draft>
        <updates>
            <doc-id>RFC1894</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2852</errata-url>
        <doi>10.17487/RFC2852</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>Generic Security Service Application Program Interface</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-cat-gssv2-javabind-05</draft>
        <obsoleted-by>
            <doc-id>RFC5653</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cat</wg_acronym>
        <doi>10.17487/RFC2853</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>HTML-INT</kw>
            <kw>HTML</kw>
            <kw>WWW</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2854</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>high performance</kw>
            <kw>serial bus</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ip1394-dhcp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ip1394</wg_acronym>
        <doi>10.17487/RFC2855</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-kzm-hcdata-types-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2856</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>Internet Protocol Security</kw>
            <kw>ESP</kw>
            <kw>encapsulating security payload</kw>
            <kw>AH</kw>
            <kw>authentication header</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-auth-hmac-ripemd-160-96-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC2857</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-idr-bgp4-multiprotocol-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2283</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4760</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2858</errata-url>
        <doi>10.17487/RFC2858</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>TSWTCM</kw>
            <kw>Time Sliding Window Three Colour Marker</kw>
            <kw>packets</kw>
            <kw>traffic</kw>
            <kw>stream</kw>
            <kw>routers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-fang-diffserv-tc-tswtcm-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2859</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-iab-iana-mou-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2860</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-handley-tcp-cwv-02</draft>
        <obsoleted-by>
            <doc-id>RFC7661</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2861</errata-url>
        <doi>10.17487/RFC2861</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Transport Protocol for Real Time Applications</kw>
            <kw>view graphs</kw>
            <kw>resolution</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>signals</kw>
        </keywords>
        <abstract><p>This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-pointer-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2862</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>INTERGRMIB</kw>
            <kw>Interfaces Group Management Information Base</kw>
            <kw>Network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ifmib-ifmib2-03</draft>
        <obsoletes>
            <doc-id>RFC2233</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8892</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2863</errata-url>
        <doi>10.17487/RFC2863</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ifmib-invstackmib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ifmib</wg_acronym>
        <doi>10.17487/RFC2864</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>Remote Authentication Dial In User Service</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network Access Server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
            <doc-id>RFC5080</doc-id>
            <doc-id>RFC6929</doc-id>
            <doc-id>RFC8044</doc-id>
            <doc-id>RFC9765</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2865</errata-url>
        <doi>10.17487/RFC2865</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-radius-accounting-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2139</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2867</doc-id>
            <doc-id>RFC5080</doc-id>
            <doc-id>RFC5997</doc-id>
            <doc-id>RFC9765</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2866</errata-url>
        <doi>10.17487/RFC2866</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>Remote Authentication Dial In User Service</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network Access Server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-radius-tunnel-acct-05</draft>
        <updates>
            <doc-id>RFC2866</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2867</errata-url>
        <doi>10.17487/RFC2867</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-radius-tunnel-auth-09</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3575</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2868</errata-url>
        <doi>10.17487/RFC2868</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-radius-ext-07</draft>
        <updated-by>
            <doc-id>RFC3579</doc-id>
            <doc-id>RFC5080</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>radius</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2869</errata-url>
        <doi>10.17487/RFC2869</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>infrastructure</kw>
            <kw>domain names</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnsop-root-opreq-05</draft>
        <obsoletes>
            <doc-id>RFC2010</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7720</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC2870</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>TRIP</kw>
            <kw>gateway</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-iptel-gwloc-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC2871</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rap-rsvp-appid-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2872</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>IPv4</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-xiao-tcp-prec-03</draft>
        <obsoleted-by>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2873</errata-url>
        <doi>10.17487/RFC2873</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]</p></abstract>
        <draft>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>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2874</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Diffie-Hellman</kw>
            <kw>certificate</kw>
            <kw>security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-dhpop-03</draft>
        <obsoleted-by>
            <doc-id>RFC6955</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC2875</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>cryptographic</kw>
            <kw>message</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-cmskea-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2876</errata-url>
        <doi>10.17487/RFC2876</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2877</doc-id>
        <title>5250 Telnet Enhancements</title>
        <author>
            <name>T. Murphy 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>client</kw>
            <kw>server</kw>
            <kw>printer</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tn3270e-tn5250e-05</draft>
        <obsoleted-by>
            <doc-id>RFC4777</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1205</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC2877</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>PPP-BCP</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC2878</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>media</kw>
            <kw>features</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract><p>This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2879</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>schema</kw>
            <kw>media</kw>
            <kw>tags</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-fax-feature-T30-mapping-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC2880</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial-up</kw>
            <kw>user service</kw>
        </keywords>
        <abstract><p>This document describes the terminology and gives a model of typical Network Access Server (NAS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nasreq-nasmodel-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>nasreq</wg_acronym>
        <doi>10.17487/RFC2881</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>NAS</kw>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial-in</kw>
            <kw>user service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nasreq-ext-radiuspract-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>nasreq</wg_acronym>
        <doi>10.17487/RFC2882</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SACK</kw>
            <kw>Extension to the Selective Acknowledgement</kw>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>packets</kw>
            <kw>sender</kw>
            <kw>receiver</kw>
        </keywords>
        <abstract><p>This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-floyd-sack-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2883</errata-url>
        <doi>10.17487/RFC2883</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>end-to-end</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hadi-jhsua-ecnperf-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2884</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>170</page-count>
        <keywords>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>megaco</wg_acronym>
        <doi>10.17487/RFC2885</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>megaco</wg_acronym>
        <doi>10.17487/RFC2886</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>application</kw>
            <kw>RM</kw>
            <kw>congestion</kw>
            <kw>control</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-design-space-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC2887</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>layer two</kw>
            <kw>tunneling</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-srisuresh-secure-ra-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2888</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>MAC</kw>
            <kw>medium</kw>
            <kw>access</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-mswitch-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2889</errata-url>
        <doi>10.17487/RFC2889</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>GRE</kw>
            <kw>generic routing encapsulation</kw>
        </keywords>
        <abstract><p>This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-dommety-gre-ext-04</draft>
        <updates>
            <doc-id>RFC2784</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2890</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ldapext-sorting-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapext</wg_acronym>
        <doi>10.17487/RFC2891</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>spatial</kw>
            <kw>reuse</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-tsiang-srp-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2892</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>TRANS-IPV6</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract><p>This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ngtrans-mech-06</draft>
        <obsoletes>
            <doc-id>RFC1933</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4213</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2893</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>operations</kw>
            <kw>scalability</kw>
            <kw>applicability</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-router-renum-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2894</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>Remote Network Monitoring</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC2895</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>RMON</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmonmib-rmonprot-mac-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC2896</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-cromwell-mgcp-advanced-audio-pkg-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2897</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>public-key</kw>
            <kw>authentication</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-kaliski-pkcs5-v2-04</draft>
        <obsoleted-by>
            <doc-id>RFC8018</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2898</errata-url>
        <doi>10.17487/RFC2898</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2899</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2800</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3000</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2900</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>address space</kw>
            <kw>routing</kw>
            <kw>database</kw>
            <kw>domain name</kw>
            <kw>registration</kw>
        </keywords>
        <abstract><p>This document describes the administrative procedures for networks seeking to connect to the global Internet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-wenzel-nsrc-02</draft>
        <is-also>
            <doc-id>FYI0037</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2901</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-rtrws-over-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2902</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-aaaarch-generic-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2903</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-aaaarch-authorization-framework-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2904</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>This memo describes several examples of applications requiring authorization.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-aaaarch-authorization-apps-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2905</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-aaaarch-authorization-reqs-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2906</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>MADCAP</kw>
            <kw>multicast address dynamic client allocation protocol</kw>
        </keywords>
        <abstract><p>This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-malloc-madcap-nest-opt-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC2907</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>MALLOC</kw>
            <kw>host server</kw>
            <kw>intra-domain</kw>
            <kw>inter-domain</kw>
        </keywords>
        <abstract><p>This document proposes a multicast address allocation architecture (MALLOC) for the Internet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-malloc-arch-05</draft>
        <obsoleted-by>
            <doc-id>RFC6308</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC2908</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>MASC</kw>
            <kw>Multicast Address-Set Claim Protocol</kw>
            <kw>inter-domain</kw>
            <kw>router</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-malloc-masc-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC2909</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>Encoding</kw>
            <kw>Transport</kw>
            <kw>application</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipp-protocol-v11-06</draft>
        <obsoletes>
            <doc-id>RFC2565</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8010</doc-id>
        </obsoleted-by>
        <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>
            <doc-id>RFC7472</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2910</errata-url>
        <doi>10.17487/RFC2910</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>224</page-count>
        <keywords>
            <kw>IPP-M-S</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>Model</kw>
            <kw>Semantics</kw>
            <kw>application</kw>
            <kw>media type</kw>
            <kw>job</kw>
        </keywords>
        <abstract><p>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipp-model-v11-07</draft>
        <obsoletes>
            <doc-id>RFC2566</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8011</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3380</doc-id>
            <doc-id>RFC3382</doc-id>
            <doc-id>RFC3996</doc-id>
            <doc-id>RFC3995</doc-id>
            <doc-id>RFC7472</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2911</errata-url>
        <doi>10.17487/RFC2911</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>tag</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-conneg-content-features-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2912</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>tag</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-conneg-feature-type-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <doi>10.17487/RFC2913</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>end-to-end</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-floyd-cong-04</draft>
        <updated-by>
            <doc-id>RFC7141</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0041</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ecm</wg_acronym>
        <doi>10.17487/RFC2914</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <doi>10.17487/RFC2915</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>E.164</kw>
        </keywords>
        <abstract><p>This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2916</errata-url>
        <doi>10.17487/RFC2916</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>virtual private networks</kw>
            <kw>multiprotocol label switching</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-muthukrishnan-mpls-corevpn-arch-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2917</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idr-bgp-route-refresh-01</draft>
        <updated-by>
            <doc-id>RFC7313</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC2918</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>server</kw>
            <kw>clients</kw>
            <kw>user agents</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-chandhok-listid-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2919</errata-url>
        <doi>10.17487/RFC2919</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SMTP-Pipe</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-freed-smtp-pipe-01</draft>
        <obsoletes>
            <doc-id>RFC2197</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0060</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2920</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-ngtrans-6bone-ptla-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC2921</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ptopomib-mib-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ptopomib</wg_acronym>
        <doi>10.17487/RFC2922</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>maximum</kw>
            <kw>unit</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tcpimpl-pmtud-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpimpl</wg_acronym>
        <doi>10.17487/RFC2923</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>data</kw>
            <kw>transport</kw>
            <kw>integrated</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-aaa-accounting-attributes-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <doi>10.17487/RFC2924</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-disman-remops-mib-08</draft>
        <obsoleted-by>
            <doc-id>RFC4560</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2925</errata-url>
        <doi>10.17487/RFC2925</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>service location</kw>
            <kw>protocol</kw>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-svrloc-template-conversion-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>svrloc</wg_acronym>
        <doi>10.17487/RFC2926</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-schema-ldap-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>schema</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2927</errata-url>
        <doi>10.17487/RFC2927</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>sub-top-level</kw>
            <kw>aggregation</kw>
            <kw>identifiers</kw>
            <kw>address</kw>
            <kw>registries</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipngwg-iana-tla-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC2928</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>internet assigned numbers authority</kw>
            <kw>resource records</kw>
            <kw>RRs</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnsext-iana-dns-01</draft>
        <obsoleted-by>
            <doc-id>RFC5395</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC2929</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>TKEY-RR</kw>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>resource record</kw>
            <kw>transaction key</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsext-tkey-04</draft>
        <updated-by>
            <doc-id>RFC6895</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC2930</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>data</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC2931</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idmr-multicast-routmib-13</draft>
        <obsoleted-by>
            <doc-id>RFC5132</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2932</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>igmp</kw>
            <kw>Internet Group Management Protocol</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idmr-igmp-mib-14</draft>
        <obsoleted-by>
            <doc-id>RFC5519</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2933</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>PIM</kw>
            <kw>Protocol Independent Multicast</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-idmr-pim-mib-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <doi>10.17487/RFC2934</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IOTP-HTTP</kw>
            <kw>Internet Open Trading Protocol</kw>
            <kw>hypertext transport protocol</kw>
            <kw>XML</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-trade-iotp-http-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC2935</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-trade-mime-detector-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC2936</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-nsso-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC2937</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>tags</kw>
            <kw>expression</kw>
            <kw>hash</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>conneg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2938</errata-url>
        <doi>10.17487/RFC2938</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2939</errata-url>
        <doi>10.17487/RFC2939</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>cops</kw>
            <kw>Common Open Policy Service</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rap-cops-client-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC2940</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>TOPT-AUTH</kw>
            <kw>Telnet Authentication Option</kw>
            <kw>encryption</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2941</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Telnet Authentication</kw>
            <kw>encryption</kw>
            <kw>Kerberos</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-tso-telnet-krb5-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2942</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TELNET</kw>
            <kw>DSA</kw>
            <kw>digital signature algorithm</kw>
        </keywords>
        <abstract><p>This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA).  It relies on the Telnet Authentication Option. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-housley-telnet-auth-dsa-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2943</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Telnet</kw>
            <kw>SRP</kw>
            <kw>secure remote password protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-wu-telnet-auth-srp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2944</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SRP</kw>
            <kw>secure remote password protocol</kw>
        </keywords>
        <abstract><p>This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-wu-srp-auth-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2945</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Telnet</kw>
            <kw>stream</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-tso-telnet-encryption-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2946</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Telnet</kw>
            <kw>Triple-DES</kw>
            <kw>data encryption standard</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-altman-telnet-enc-des3-cfb-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2947</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Telnet</kw>
            <kw>DES</kw>
            <kw>data encryption standard</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-altman-telnet-enc-des3-ofb-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2948</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>CAST-128</kw>
            <kw>Telnet</kw>
            <kw>encryption</kw>
            <kw>algorithm</kw>
            <kw>option</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-altman-telnet-enc-cast128-ofb-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2949</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>CAST-128</kw>
            <kw>Telnet</kw>
            <kw>encryption</kw>
            <kw>algorithm</kw>
            <kw>option</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-altman-telnet-enc-cast128-cfb-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2950</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>key exchange</kw>
            <kw>algorithm</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-housley-telnet-auth-keasj-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2951</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>data</kw>
            <kw>encryption</kw>
            <kw>standard</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-tso-telnet-enc-des-cfb-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2952</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>data</kw>
            <kw>encryption</kw>
            <kw>standard</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-tso-telnet-enc-des-ofb-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2953</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>FR-MIB</kw>
            <kw>Frame Relay Service</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-frnetmib-frs-mib-12</draft>
        <obsoletes>
            <doc-id>RFC1604</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>frnetmib</wg_acronym>
        <doi>10.17487/RFC2954</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>PVC</kw>
            <kw>permanent virtual connections</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-frnetmib-atmiwf-06</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>frnetmib</wg_acronym>
        <doi>10.17487/RFC2955</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>intenret</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-ntwlyrws-over-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2956</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>media-types</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-daigle-wppquery-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2957</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>media-types</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-daigle-wppresp-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2958</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-Time Transport Protocol</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-mib-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC2959</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>134</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>transport</kw>
            <kw>packet</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sigtran-sctp-13</draft>
        <obsoleted-by>
            <doc-id>RFC4960</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3309</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2960</errata-url>
        <doi>10.17487/RFC2960</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>messages</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rsvp-refresh-reduct-05</draft>
        <updated-by>
            <doc-id>RFC5063</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC2961</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-snmp-alg-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2962</errata-url>
        <doi>10.17487/RFC2962</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RAS</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>diffserv</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bonaventure-diffserv-rashaper-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2963</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC2964</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
        </keywords>
        <abstract><p>This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-http-state-man-mec-12</draft>
        <obsoletes>
            <doc-id>RFC2109</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6265</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>http</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2965</errata-url>
        <doi>10.17487/RFC2965</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>intermediate</kw>
            <kw>system</kw>
            <kw>routers</kw>
            <kw>loops</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-domain-wide-03</draft>
        <obsoleted-by>
            <doc-id>RFC5302</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC2966</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>105</page-count>
        <keywords>
            <kw>single</kw>
            <kw>point</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-daigle-tisdag-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2967</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-daigle-dag-mesh-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2968</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>technical</kw>
            <kw>infrastructure</kw>
            <kw>swedish</kw>
            <kw>access</kw>
            <kw>gateways</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-eklof-dag-experiences-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2969</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ids</kw>
            <kw>whitepages</kw>
            <kw>technical</kw>
            <kw>infrastructure</kw>
            <kw>swedish</kw>
            <kw>access</kw>
            <kw>gateways</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-daigle-arch-ids-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC2970</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IMAP4</kw>
            <kw>internet message access protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-showalter-imap-id-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2971</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CNRP</kw>
        </keywords>
        <abstract><p>This document establishes the context and goals for a Common Name Resolution Protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-cnrp-goals-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2972</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>intermediate</kw>
            <kw>system</kw>
            <kw>PDU</kw>
            <kw>protocol data</kw>
            <kw>unit</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-wg-mesh-group-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC2973</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SAP</kw>
            <kw>Session Announcement Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mmusic-sap-v2-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC2974</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>resource</kw>
            <kw>consumption data</kw>
            <kw>cost allocation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-aaa-acct-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <doi>10.17487/RFC2975</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>session initiation protocol</kw>
            <kw>information</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-info-method-05</draft>
        <obsoleted-by>
            <doc-id>RFC6086</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC2976</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mobileip-aaa-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC2977</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>character</kw>
            <kw>set</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2978</errata-url>
        <doi>10.17487/RFC2978</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>security</kw>
            <kw>intranet</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-firewall-req-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2979</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>network</kw>
            <kw>news</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nntpext-imp-04</draft>
        <updated-by>
            <doc-id>RFC3977</doc-id>
            <doc-id>RFC4643</doc-id>
            <doc-id>RFC4644</doc-id>
            <doc-id>RFC6048</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>nntpext</wg_acronym>
        <doi>10.17487/RFC2980</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2981</doc-id>
        <title>Event MIB</title>
        <author>
            <name>R. Kavasseri</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>Event</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-disman-event-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2981</errata-url>
        <doi>10.17487/RFC2981</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2982</doc-id>
        <title>Distributed Management Expression MIB</title>
        <author>
            <name>R. Kavasseri</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>Distributed Management Expression</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-disman-express-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC2982</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-diffserv-tunnels-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC2983</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>CAST-128</kw>
            <kw>CMS</kw>
            <kw>cryptographic message syntax</kw>
            <kw>security</kw>
            <kw>cipher</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-cast-128-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC2984</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-nystrom-pkcs9-v2-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2985</errata-url>
        <doi>10.17487/RFC2985</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-nystrom-pkcs10-v1-7-00</draft>
        <obsoletes>
            <doc-id>RFC2314</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5967</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc2986</errata-url>
        <doi>10.17487/RFC2986</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Charset</kw>
            <kw>character sets</kw>
            <kw>human</kw>
            <kw>languages</kw>
            <kw>devices</kw>
        </keywords>
        <abstract><p>This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hoffman-char-lang-media-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2987</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-paxson-tcp-rto-01</draft>
        <obsoleted-by>
            <doc-id>RFC6298</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc2988</errata-url>
        <doi>10.17487/RFC2988</doi>
    </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>P. Walsh</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>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>H. Koo</name>
        </author>
        <author>
            <name>M. Lipford</name>
        </author>
        <author>
            <name>E. Campbell</name>
        </author>
        <author>
            <name>Y. Xu</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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-aaa-na-reqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <doi>10.17487/RFC2989</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>quality of service</kw>
            <kw>end-to-end</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-qos-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2990</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>forwarding</kw>
            <kw>packets</kw>
            <kw>ECMP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-thaler-multipath-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2991</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ECMP</kw>
            <kw>routing</kw>
            <kw>packets</kw>
            <kw>forwarding</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hopps-ecmp-algo-analysis-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2992</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>network</kw>
            <kw>address</kw>
            <kw>translation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-nat-implications-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC2993</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>cryptosystem</kw>
            <kw>security</kw>
            <kw>data</kw>
            <kw>stream</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ohta-misty1desc-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2994</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>public</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-spirits-implementations-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>spirits</wg_acronym>
        <doi>10.17487/RFC2995</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
        </keywords>
        <abstract><p>This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-issll-dclass-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2996</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-issll-nullservice-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2997</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>intserv</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
            <kw>end-to-end</kw>
        </keywords>
        <abstract><p>This document describes a framework by which Integrated Services may be supported over Diffserv networks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-issll-diffserv-rsvp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC2998</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC2999</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC2900</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3300</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3000</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>OIDs</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs).  This memo provides information for the Internet community.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3001</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-wirelessws-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3002</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>audio/mpeg</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>Media Type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-nilsson-audio-mpeg-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3003</errata-url>
        <doi>10.17487/RFC3003</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-userclass-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3004</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-poisson-listaup-02</draft>
        <obsoleted-by>
            <doc-id>RFC9245</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8717</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC3005</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>resource</kw>
            <kw>allocation</kw>
            <kw>int-serv</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-intserv-compress-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>intserv</wg_acronym>
        <doi>10.17487/RFC3006</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>validation</kw>
            <kw>DNSSEC</kw>
            <kw>Domain Name System</kw>
        </keywords>
        <abstract><p>This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3007</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>authentication</kw>
            <kw>validation</kw>
            <kw>SIG</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsext-signing-auth-02</draft>
        <obsoleted-by>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3008</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>parityfec</kw>
            <kw>media type</kw>
            <kw>MIME</kw>
            <kw>multimedia internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-fecmime-01</draft>
        <obsoleted-by>
            <doc-id>RFC5109</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3009</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>212</page-count>
        <keywords>
            <kw>NFSv4</kw>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-07</draft>
        <obsoleted-by>
            <doc-id>RFC3530</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3010</errata-url>
        <doi>10.17487/RFC3010</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-subnet-option-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3011</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>authentication</kw>
            <kw>foreign</kw>
            <kw>agent</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mobileip-challenge-13</draft>
        <obsoleted-by>
            <doc-id>RFC4721</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC3012</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ISPs</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grip</wg_acronym>
        <doi>10.17487/RFC3013</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>Notification Log</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-disman-notif-log-mib-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC3014</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>179</page-count>
        <keywords>
            <kw>MEGACO</kw>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>megaco</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3015</errata-url>
        <doi>10.17487/RFC3015</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-mpeg4-es-05</draft>
        <obsoleted-by>
            <doc-id>RFC6416</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3016</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>extensible markup language</kw>
            <kw>DTD</kw>
            <kw>document type declaration</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-roamops-phonebook-xml-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>roamops</wg_acronym>
        <doi>10.17487/RFC3017</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>UMSP</kw>
            <kw>Unified Memory Space Protocol</kw>
            <kw>network</kw>
            <kw>connection oriented</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bogdanov-umsp</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3018</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Internet Protocol</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>MLD</kw>
            <kw>Multicast Listener Discovery Protocol</kw>
        </keywords>
        <abstract><p>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 [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipngwg-mld-mib-05</draft>
        <obsoleted-by>
            <doc-id>RFC5519</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC3019</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-frnetmib-mfrmib-04</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>frnetmib</wg_acronym>
        <doi>10.17487/RFC3020</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>addresses</kw>
            <kw>subnet masks</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-retana-31bits-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3021</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ports</kw>
            <kw>private</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-traditional-05</draft>
        <obsoletes>
            <doc-id>RFC1631</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3022</errata-url>
        <doi>10.17487/RFC3022</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>extensible markup language</kw>
            <kw>web</kw>
            <kw>authority</kw>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-murata-xml-09</draft>
        <obsoletes>
            <doc-id>RFC2376</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7303</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2048</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6839</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3023</errata-url>
        <doi>10.17487/RFC3023</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Mobile IP</kw>
            <kw>internet protocol</kw>
            <kw>node</kw>
            <kw>care-of-address</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3024</errata-url>
        <doi>10.17487/RFC3024</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC3025</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-itu-sg2-liason-enum-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3026</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>address</kw>
            <kw>translator</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-protocol-complications-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <doi>10.17487/RFC3027</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Sieve</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-showalter-sieve-12</draft>
        <obsoleted-by>
            <doc-id>RFC5228</doc-id>
            <doc-id>RFC5429</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3028</errata-url>
        <doi>10.17487/RFC3028</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>PKI</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>DVCS</kw>
            <kw>Data Validation and Certification Server</kw>
            <kw>TTP</kw>
            <kw>trusted third party</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pkix-dcs-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3029</errata-url>
        <doi>10.17487/RFC3029</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3030</errata-url>
        <doi>10.17487/RFC3030</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Multiprotocol Label Switching</kw>
        </keywords>
        <abstract><p>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-arch-06</draft>
        <updated-by>
            <doc-id>RFC6178</doc-id>
            <doc-id>RFC6790</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3031</errata-url>
        <doi>10.17487/RFC3031</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>multi-protocol label switching</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-label-encaps-07</draft>
        <updated-by>
            <doc-id>RFC3443</doc-id>
            <doc-id>RFC4182</doc-id>
            <doc-id>RFC5332</doc-id>
            <doc-id>RFC3270</doc-id>
            <doc-id>RFC5129</doc-id>
            <doc-id>RFC5462</doc-id>
            <doc-id>RFC5586</doc-id>
            <doc-id>RFC7274</doc-id>
            <doc-id>RFC9017</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3032</errata-url>
        <doi>10.17487/RFC3032</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>Internet Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-git-uus-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3033</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>multi-protocol label switching</kw>
        </keywords>
        <abstract><p>This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-fr-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3034</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>multi-protocol label switching</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>LDP</kw>
            <kw>label distribution protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-atm-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3035</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>132</page-count>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-ldp-11</draft>
        <obsoleted-by>
            <doc-id>RFC5036</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3036</errata-url>
        <doi>10.17487/RFC3036</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-ldp-applic-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3037</errata-url>
        <doi>10.17487/RFC3037</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>VCID</kw>
            <kw>Virtual Connection Identifier</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>LDP</kw>
            <kw>label distribution protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-vcid-atm-05</draft>
        <updated-by>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3038</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC3039</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>infrastructure</kw>
            <kw>www</kw>
            <kw>world</kw>
            <kw>wide</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-wrec-taxonomy-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>wrec</wg_acronym>
        <doi>10.17487/RFC3040</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>interface</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract><p>This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipngwg-addrconf-privacy-04</draft>
        <obsoleted-by>
            <doc-id>RFC4941</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3041</errata-url>
        <doi>10.17487/RFC3041</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-limited-xmit-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3042</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-mealling-pin-urn-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3043</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>serials</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-rozenfeld-urn-issn-00</draft>
        <obsoleted-by>
            <doc-id>RFC8254</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3044</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>DSA-specific</kw>
            <kw>entry</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-mmeredith-rootdse-vendor-info-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3045</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-agent-options-12</draft>
        <updated-by>
            <doc-id>RFC6607</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3046</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ITU-T</kw>
            <kw>international telecommunication union</kw>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-g7221-01</draft>
        <obsoleted-by>
            <doc-id>RFC5577</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3047</errata-url>
        <doi>10.17487/RFC3047</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>RMT</kw>
            <kw>protocol</kw>
            <kw>core</kw>
        </keywords>
        <abstract><p>This document describes a framework for the standardization of bulk-data reliable multicast transport.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rmt-buildingblocks-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3048</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tn3270e-service-loc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>tn3270e</wg_acronym>
        <doi>10.17487/RFC3049</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>session</kw>
            <kw>initiation</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This document defines a SIP CGI interface for providing SIP services on a SIP server.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-lennox-sip-cgi-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3050</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>international</kw>
            <kw>telecommunication</kw>
            <kw>union</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-heath-ipcomp-v44-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3051</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>framework</kw>
            <kw>packets</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-nsmrg-sm-issues-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3052</errata-url>
        <doi>10.17487/RFC3052</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>infrastructure</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ngtrans-broker-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC3053</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>H.248</kw>
            <kw>telephone</kw>
            <kw>MG</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-megaco-ipphone-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>megaco</wg_acronym>
        <doi>10.17487/RFC3054</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>PINT</kw>
            <kw>PSTN/Internet Interworking Services Architecture</kw>
        </keywords>
        <abstract><p>This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pint-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pint</wg_acronym>
        <doi>10.17487/RFC3055</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>WAN</kw>
            <kw>wide area network</kw>
            <kw>unicast</kw>
            <kw>point-to-point</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ngtrans-6to4-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3056</errata-url>
        <doi>10.17487/RFC3056</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>signaling</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sigtran-iua-10</draft>
        <obsoleted-by>
            <doc-id>RFC4233</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3807</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3057</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-smime-idea-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3058</errata-url>
        <doi>10.17487/RFC3058</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SLPv2</kw>
            <kw>Service Location Protocol</kw>
            <kw>messages</kw>
            <kw>user agent</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-guttman-svrloc-attrlist-ext-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3059</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>CIM</kw>
            <kw>common information model</kw>
            <kw>schema</kw>
            <kw>object-oriented</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>policy</wg_acronym>
        <doi>10.17487/RFC3060</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>OIDs</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mealling-rfc3001bis-01</draft>
        <obsoletes>
            <doc-id>RFC3001</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3061</errata-url>
        <doi>10.17487/RFC3061</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-zeilenga-ldap-passwd-exop-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3062</errata-url>
        <doi>10.17487/RFC3062</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>multiprotocol label switching</kw>
            <kw>path</kw>
            <kw>LSPs</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-loop-prevention-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3063</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>controllers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-foster-mgcp-cas-packages-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3064</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>BGP-ASC</kw>
            <kw>Autonomous System Confederations</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idr-bgp-confed-rfc1965bis-01</draft>
        <obsoletes>
            <doc-id>RFC1965</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5065</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3065</errata-url>
        <doi>10.17487/RFC3065</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Lang-Tag</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-alvestrand-lang-tag-v2-05</draft>
        <obsoletes>
            <doc-id>RFC1766</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4646</doc-id>
            <doc-id>RFC4647</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3066</errata-url>
        <doi>10.17487/RFC3066</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IEDEF</kw>
            <kw>data</kw>
            <kw>archiving</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-terena-itdwg-iodef-requirements-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3067</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>6to4</kw>
            <kw>exterior gateway protocol</kw>
            <kw>EGP</kw>
            <kw>IGP</kw>
            <kw>interior</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ngtrans-6to4anycast-03</draft>
        <obsoleted-by>
            <doc-id>RFC7526</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC3068</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>virtual</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-mcpherson-vlan-ipagg-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3069</errata-url>
        <doi>10.17487/RFC3069</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>L2TP-FR</kw>
            <kw>Layer Two Tunneling Protocol</kw>
            <kw>Frame Relay</kw>
            <kw>point-to-point</kw>
            <kw>PVCs</kw>
            <kw>Permanent Virtual Circuits</kw>
            <kw>SVCs</kw>
            <kw>Switched Virtual Circuits</kw>
        </keywords>
        <abstract><p>This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-fr-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3070</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Policy</kw>
            <kw>Top-Level</kw>
            <kw>TLD</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-klensin-1591-reflections-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3071</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>chunks</kw>
            <kw>file</kw>
            <kw>datatype</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-wildgrube-sdxf-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3072</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-collins-pfr-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3073</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DHC</kw>
            <kw>dynamic host configuration</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-loadb-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3074</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract><p>This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>xmldsig</wg_acronym>
        <doi>10.17487/RFC3075</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-xmldsig-canonical-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>xmldsig</wg_acronym>
        <doi>10.17487/RFC3076</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>LL</kw>
            <kw>Link-Layer</kw>
            <kw>udl</kw>
            <kw>Unidirectional link</kw>
            <kw>bidirectional</kw>
            <kw>connectivity</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-udlr-lltunnel-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>udlr</wg_acronym>
        <doi>10.17487/RFC3077</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>security</kw>
            <kw>ppp</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pppext-mppe-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3078</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>security</kw>
            <kw>ppp</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pppext-mppe-keys-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3079</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>BEEP</kw>
            <kw>Blocks Extensible Exchange Protocol</kw>
            <kw>text</kw>
            <kw>binary</kw>
            <kw>messages</kw>
            <kw>kernel</kw>
        </keywords>
        <abstract><p>This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-beep-framework-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>beep</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3080</errata-url>
        <doi>10.17487/RFC3080</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>BEEP</kw>
            <kw>blocks extensible exchange protocol</kw>
        </keywords>
        <abstract><p>This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-beep-tcpmapping-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>beep</wg_acronym>
        <doi>10.17487/RFC3081</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>service location protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-kempf-srvloc-notify-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3082</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>BPI</kw>
            <kw>data-over-cable</kw>
            <kw>service interface</kw>
            <kw>specifications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipcdn-mcns-bpi-mib-02</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3083</errata-url>
        <doi>10.17487/RFC3083</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>COPS-PR</kw>
            <kw>common open policy service</kw>
            <kw>security</kw>
            <kw>quality</kw>
            <kw>provisioning</kw>
        </keywords>
        <abstract><p>This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rap-pr-05</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3084</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>newsitems</kw>
            <kw>iptc</kw>
        </keywords>
        <abstract><p>This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iptc-newsml-urn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3085</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>diffserv</kw>
            <kw>QoS</kw>
            <kw>quality of service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-diffserv-pdb-def-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC3086</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>session</kw>
            <kw>initiation</kw>
            <kw>protocol</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-campbell-sip-service-control-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3087</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>OpenLDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zeilenga-ldap-root-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3088</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>application</kw>
            <kw>layer</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ngtrans-socks-gateway-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC3089</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>rsa</kw>
            <kw>dsa</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3090</doi>
    </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>1</day>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3091</errata-url>
        <doi>10.17487/RFC3091</doi>
    </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>1</day>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3092</errata-url>
        <doi>10.17487/RFC3092</doi>
    </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>1</day>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3093</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>106</page-count>
        <keywords>
            <kw>signaling</kw>
            <kw>gatewa</kw>
            <kw>circuit</kw>
            <kw>network</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-benedyk-sigtran-tali-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3094</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>168</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>RObust Header Compression</kw>
            <kw>ESP</kw>
            <kw>encapsulating security payload</kw>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>UDP</kw>
            <kw>user datagram protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rohc-rtp-09</draft>
        <updated-by>
            <doc-id>RFC3759</doc-id>
            <doc-id>RFC4815</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3095</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rohc-rtp-requirements-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3096</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rsvp</wg_acronym>
        <doi>10.17487/RFC3097</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>marketing</kw>
            <kw>users</kw>
            <kw>service</kw>
            <kw>providers</kw>
            <kw>isps</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>run</wg_acronym>
        <doi>10.17487/RFC3098</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3099</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>OSPF-NSSA</kw>
            <kw>Open Shortest Path First</kw>
            <kw>Not-So-Stubby Area</kw>
            <kw>external routes</kw>
            <kw>backward compatible</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3101</errata-url>
        <doi>10.17487/RFC3101</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>RSIP</kw>
            <kw>Realm Specific Internet Protocol</kw>
            <kw>end-to-end</kw>
            <kw>NAT</kw>
            <kw>addressing</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-rsip-framework-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <doi>10.17487/RFC3102</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>RSIP</kw>
            <kw>Realm Specific Internet Protocol</kw>
            <kw>host</kw>
            <kw>gateway</kw>
            <kw>NAT</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-rsip-protocol-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <doi>10.17487/RFC3103</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RSIP</kw>
            <kw>realm specific internet protocol</kw>
            <kw>NAT</kw>
            <kw>addressing</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-rsip-ipsec-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3104</errata-url>
        <doi>10.17487/RFC3104</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RSIP</kw>
            <kw>realm specific internet protocol</kw>
            <kw>SLP</kw>
            <kw>service location protocol</kw>
            <kw>NAT</kw>
            <kw>addressing</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-rsip-slp-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <doi>10.17487/RFC3105</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>electronic</kw>
            <kw>modeling</kw>
            <kw>language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-eastlake-ecom-fields2-05</draft>
        <obsoletes>
            <doc-id>RFC2706</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4112</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3106</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>BGP</kw>
            <kw>Border Gateway Protocol</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>AAL</kw>
            <kw>ATM Adaptation Layer</kw>
            <kw>syntax</kw>
            <kw>adaption</kw>
            <kw>layer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-bgp4-mpls-04</draft>
        <obsoleted-by>
            <doc-id>RFC8277</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6790</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3107</errata-url>
        <doi>10.17487/RFC3107</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>110</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>AAL</kw>
            <kw>ATM Adaptation Layer</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-atm-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3108</errata-url>
        <doi>10.17487/RFC3108</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>BBN 1822</kw>
            <kw>host</kw>
            <kw>imp</kw>
            <kw>arpanet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ymbk-std39-historic-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3109</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RSA/SHA1</kw>
            <kw>RRs</kw>
            <kw>resource records</kw>
            <kw>security</kw>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsext-rsa-03</draft>
        <obsoletes>
            <doc-id>RFC2537</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6944</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3110</errata-url>
        <doi>10.17487/RFC3110</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-svrloc-ipv6-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>svrloc</wg_acronym>
        <doi>10.17487/RFC3111</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zeilenga-ldap-authpasswd-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3112</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
            <kw>third generation</kw>
            <kw>partnership project</kw>
        </keywords>
        <abstract><p>This document describes the standardization collaboration between 3GPP and IETF.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-3gpp-collaboration-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3113</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-smime-seclabel-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3114</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Mobile IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC3025</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC3115</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>127</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer mode</kw>
            <kw>formats</kw>
            <kw>switching</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-atm-method-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC3116</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>beep</kw>
            <kw>bxxp</kw>
            <kw>blocks</kw>
            <kw>extensible</kw>
            <kw>exchange</kw>
            <kw>text</kw>
            <kw>binary</kw>
        </keywords>
        <abstract><p>This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mrose-beep-design-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3118</doc-id>
        <title>Authentication for DHCP Messages</title>
        <author>
            <name>R. Droms</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Arbaugh</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>verification</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-authentication-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3118</errata-url>
        <doi>10.17487/RFC3118</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time protocol</kw>
            <kw>MPEG</kw>
            <kw>moving picture experts group</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-mp3-06</draft>
        <obsoleted-by>
            <doc-id>RFC5219</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3119</errata-url>
        <doi>10.17487/RFC3119</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-best-xmlorg-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3120</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>organization for the advancement of structured information standards</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-best-urn-oasis-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3121</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>IND</kw>
            <kw>Inverse Neighbor Discovery</kw>
            <kw>link-layer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ion-ipv6-ind-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3122</errata-url>
        <doi>10.17487/RFC3122</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
            <kw>resource record</kw>
            <kw>APL</kw>
            <kw>address prefix lists</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnsext-apl-rr-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3123</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>CM</kw>
            <kw>Congestion Manager</kw>
            <kw>network</kw>
            <kw>stream</kw>
            <kw>end-system module</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ecm-cm-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ecm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3124</errata-url>
        <doi>10.17487/RFC3124</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>electronic</kw>
            <kw>signature</kw>
            <kw>signer</kw>
            <kw>purchase</kw>
            <kw>contract</kw>
            <kw>invoice</kw>
            <kw>transactions</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-espolicies-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3125</errata-url>
        <doi>10.17487/RFC3125</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>purchase</kw>
            <kw>contract</kw>
            <kw>invoice</kw>
            <kw>application</kw>
            <kw>smart cards</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-esformats-03</draft>
        <obsoleted-by>
            <doc-id>RFC5126</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3126</errata-url>
        <doi>10.17487/RFC3126</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>network</kw>
            <kw>access</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-aaa-proto-eval-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <doi>10.17487/RFC3127</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>firewalls</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-miller-rfc1858-cmts-00</draft>
        <updates>
            <doc-id>RFC1858</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3128</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>KINK</kw>
            <kw>cryptographic</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-kink-reqmt-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kink</wg_acronym>
        <doi>10.17487/RFC3129</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>security</kw>
            <kw>extensions</kw>
            <kw>report</kw>
        </keywords>
        <abstract><p>This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-lewis-state-of-dnssec-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3130</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
            <kw>third generation</kw>
            <kw>partnership project</kw>
        </keywords>
        <abstract><p>This document describes the standardization collaboration between 3GPP2 and IETF.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-bradner-3gpp2-collaboration-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3131</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>molulity</kw>
            <kw>radio</kw>
            <kw>link</kw>
            <kw>internet</kw>
            <kw>protocl</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-seamoby-paging-problem-statement-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC3132</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>switching</kw>
            <kw>devices</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-fr-term-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC3133</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>available</kw>
            <kw>bit rate</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-atm-term-abr-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC3134</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>PEP</kw>
            <kw>PILC</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pilc-pep-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <doi>10.17487/RFC3135</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PSTN</kw>
            <kw>public</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-spirits-architecture-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>spirits</wg_acronym>
        <doi>10.17487/RFC3136</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ospf-stub-adv-02</draft>
        <obsoleted-by>
            <doc-id>RFC6987</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC3137</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>address</kw>
            <kw>AS</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
            <kw>number</kw>
        </keywords>
        <abstract><p>This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mboned-glop-extensions-02</draft>
        <obsoleted-by>
            <doc-id>RFC5771</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC3138</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ops-ip-config-management-reqmnts-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3139</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>PHB</kw>
            <kw>Per Hop Behavior</kw>
            <kw>differentiated services codepoint</kw>
            <kw>DSCP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC3140</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hiller-cdma2000-aaa-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3141</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TRT</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>The document describes an IPv6-to-IPv4 transport relay translator (TRT).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ngtrans-tcpudp-relay-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC3142</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>www</kw>
            <kw>world wide web</kw>
            <kw>hypertext transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-cooper-wrec-known-prob-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3143</errata-url>
        <doi>10.17487/RFC3143</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>remote</kw>
            <kw>monitoring</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-iftopn-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3144</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>layer 2 tunneling protocol</kw>
            <kw>PPP</kw>
            <kw>point-to-point</kw>
            <kw>accounting</kw>
            <kw>debugging</kw>
        </keywords>
        <abstract><p>This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3145</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>link-local</kw>
            <kw>addresses</kw>
            <kw>statelessly</kw>
            <kw>autoconfigured</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-1394-02</draft>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC3146</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>connectionless</kw>
            <kw>network</kw>
            <kw>service</kw>
            <kw>GRE</kw>
            <kw>layer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3147</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>BTC</kw>
            <kw>transport</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ippm-btc-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC3148</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
            <kw>packages</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-srinath-mgcp-bus-packages-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3149</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>PILC</kw>
            <kw>data</kw>
            <kw>applications</kw>
            <kw>header</kw>
            <kw>compression</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <doi>10.17487/RFC3150</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>publicid</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-walsh-urn-publicid-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3151</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>DNS</kw>
            <kw>zone</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3152</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>multiplexing</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pppext-pppmux-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3153</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>paging</kw>
            <kw>mobile</kw>
            <kw>hosts</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-seamoby-paging-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC3154</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <doi>10.17487/RFC3155</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MIME-PGP</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>Pretty Good Privacy</kw>
            <kw>Authentication</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>openpgp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3156</errata-url>
        <doi>10.17487/RFC3156</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>SACRED</kw>
            <kw>trusted roots</kw>
            <kw>private keys</kw>
            <kw>PSE</kw>
            <kw>personal security environment</kw>
        </keywords>
        <abstract><p>This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sacred-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacred</wg_acronym>
        <doi>10.17487/RFC3157</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>transport protocol</kw>
        </keywords>
        <abstract><p>This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-avt-rtptest-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3158</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>PIB</kw>
            <kw>Policy Information Base</kw>
            <kw>SNMP</kw>
            <kw>simple network management protocol</kw>
            <kw>SPPI</kw>
            <kw>Structure of Policy Provisioning Information</kw>
            <kw>SMI</kw>
            <kw>Structure of Management Information</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rap-sppi-07</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3159</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
            <kw>Meeting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-uswg-tao-06</draft>
        <obsoletes>
            <doc-id>RFC1718</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4677</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>uswg</wg_acronym>
        <doi>10.17487/RFC3160</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>TSA</kw>
            <kw>Time Stamping Authority</kw>
            <kw>TSP</kw>
            <kw>Time-Stamp Protocol</kw>
            <kw>security</kw>
            <kw>request</kw>
            <kw>response</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-time-stamp-15</draft>
        <updated-by>
            <doc-id>RFC5816</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3161</errata-url>
        <doi>10.17487/RFC3161</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>remote authentication dial in user service</kw>
            <kw>attributes</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-aboba-radius-ipv6-10</draft>
        <updated-by>
            <doc-id>RFC8044</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3162</errata-url>
        <doi>10.17487/RFC3162</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SASL</kw>
            <kw>simple authentication security layer</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zuccherato-9798-3-sasl-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3163</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>berkeley</kw>
            <kw>software</kw>
            <kw>distribution</kw>
            <kw>transmission</kw>
            <kw>messages</kw>
        </keywords>
        <abstract><p>This document describes the observed behavior of the syslog protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-syslog-syslog-12</draft>
        <obsoleted-by>
            <doc-id>RFC5424</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <doi>10.17487/RFC3164</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3165</errata-url>
        <doi>10.17487/RFC3165</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>BGP-OSPF</kw>
            <kw>Border gateway protocol</kw>
            <kw>Open shortest path first routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-meyer-rfc1403-historic-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3166</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-meyer-rfc1745-historic-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3167</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>header</kw>
            <kw>ECN</kw>
            <kw>Explicit Congestion Notification</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-04</draft>
        <obsoletes>
            <doc-id>RFC2481</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2003</doc-id>
            <doc-id>RFC2474</doc-id>
            <doc-id>RFC2401</doc-id>
            <doc-id>RFC0793</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4301</doc-id>
            <doc-id>RFC6040</doc-id>
            <doc-id>RFC8311</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3168</errata-url>
        <doi>10.17487/RFC3168</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NAS</kw>
            <kw>network</kw>
            <kw>device</kw>
            <kw>AAA</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>This document defines requirements for protocols used by Network Access Servers (NAS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nasreq-criteria-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>nasreq</wg_acronym>
        <doi>10.17487/RFC3169</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mboned-mcast-apps-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC3170</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>protocol</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mboned-iana-ipv4-mcast-guidelines-04</draft>
        <obsoleted-by>
            <doc-id>RFC5771</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3171</errata-url>
        <doi>10.17487/RFC3171</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>database</kw>
            <kw>DNS</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-arpa-03</draft>
        <updated-by>
            <doc-id>RFC9120</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0052</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3172</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IPCOMP</kw>
            <kw>internet protocol payload compression protocol</kw>
            <kw>datagram</kw>
            <kw>lossless</kw>
        </keywords>
        <abstract><p>This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-shacham-ippcp-rfc2393bis-08</draft>
        <obsoletes>
            <doc-id>RFC2393</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3173</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>FIPS</kw>
            <kw>federal</kw>
            <kw>information</kw>
            <kw>processing</kw>
            <kw>standard</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-eastlake-sha1-02</draft>
        <updated-by>
            <doc-id>RFC4634</doc-id>
            <doc-id>RFC6234</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3174</errata-url>
        <doi>10.17487/RFC3174</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>internet</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-issll-rsvp-aggr-04</draft>
        <updated-by>
            <doc-id>RFC5350</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>issll</wg_acronym>
        <doi>10.17487/RFC3175</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>agent</kw>
            <kw>data</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-phaal-sflow-montraffic-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3176</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
            <kw>engineering</kw>
            <kw>steering</kw>
            <kw>group</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iesg-ipv6-addressing-recommendations-03</draft>
        <obsoleted-by>
            <doc-id>RFC6177</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC3177</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ISP</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipngwg-ipv6-2260-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipngwg</wg_acronym>
        <doi>10.17487/RFC3178</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SMX</kw>
            <kw>Script MIB extensibility protocol</kw>
            <kw>language</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-schoenw-rfc-2593-update-04</draft>
        <obsoletes>
            <doc-id>RFC2593</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3179</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>static</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3180</errata-url>
        <doi>10.17487/RFC3180</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>rsvp</kw>
            <kw>resource reservation protocol</kw>
            <kw>cops</kw>
            <kw>common open policy service</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3181</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3182</errata-url>
        <doi>10.17487/RFC3182</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>S/MIME</kw>
            <kw>secure/multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-domsec-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3183</errata-url>
        <doi>10.17487/RFC3183</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-poisson-code-04</draft>
        <obsoleted-by>
            <doc-id>RFC7154</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>poisson</wg_acronym>
        <doi>10.17487/RFC3184</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>Content Encryption Keys</kw>
            <kw>cryptographic</kw>
            <kw>message</kw>
            <kw>syntax</kw>
            <kw>data</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-rcek-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3185</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>multiple</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>over</kw>
            <kw>SONET/SDH</kw>
            <kw>point-to-point</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-shimizu-ppp-mapos-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3186</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>isbn</kw>
            <kw>urn</kw>
            <kw>bibliographic</kw>
            <kw>identifiers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hakala-isbn-01</draft>
        <obsoleted-by>
            <doc-id>RFC8254</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3187</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>urn</kw>
            <kw>nbn</kw>
            <kw>national</kw>
            <kw>libraries</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hakala-nbn-01</draft>
        <obsoleted-by>
            <doc-id>RFC8458</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3188</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-dv-video-04</draft>
        <obsoleted-by>
            <doc-id>RFC6469</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3189</errata-url>
        <doi>10.17487/RFC3189</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>digital</kw>
            <kw>audio</kw>
            <kw>tape</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-dv-audio-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3190</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>MIN-PSTN</kw>
            <kw>Minimal GSTN</kw>
            <kw>global switched telephone network</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3191</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MINFAX-IM</kw>
            <kw>Minimal FAX Internet Mail</kw>
            <kw>facsimile</kw>
            <kw>GSTN</kw>
            <kw>global switched telephone network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3192</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>layer two tunneling protocol</kw>
            <kw>authentication</kw>
            <kw>IP Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-l2tpext-security-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3193</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3194</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>mappings</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
            <kw>beep</kw>
            <kw>blocks</kw>
            <kw>extensible</kw>
            <kw>exchange</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-syslog-reliable-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <doi>10.17487/RFC3195</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>IPP</kw>
            <kw>client</kw>
            <kw>object</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3196</errata-url>
        <doi>10.17487/RFC3196</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-dnsext-dnsmib-historical-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3197</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>glossary</kw>
            <kw>network</kw>
            <kw>ISDs</kw>
            <kw>internet</kw>
            <kw>standard</kw>
            <kw>documents</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-policy-terminology-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>policy</wg_acronym>
        <doi>10.17487/RFC3198</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3199</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-frnetmib-frsi-04</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>frnetmib</wg_acronym>
        <doi>10.17487/RFC3201</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-frnetmib-frmrelay-service-06</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>frnetmib</wg_acronym>
        <doi>10.17487/RFC3202</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>forcerenew</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-pv4-reconfigure-06</draft>
        <updated-by>
            <doc-id>RFC6704</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3203</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipart internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-isup-mime-10</draft>
        <updated-by>
            <doc-id>RFC3459</doc-id>
            <doc-id>RFC5621</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3204</errata-url>
        <doi>10.17487/RFC3204</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>layering</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-moore-using-http-01</draft>
        <obsoleted-by>
            <doc-id>RFC9205</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3205</errata-url>
        <doi>10.17487/RFC3205</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-gellens-pop-err-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3206</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>ssl</kw>
            <kw>tls</kw>
            <kw>Transport Layer Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-hoffman-rfc2487bis-06</draft>
        <obsoletes>
            <doc-id>RFC2487</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7817</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3207</errata-url>
        <doi>10.17487/RFC3207</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>111</page-count>
        <keywords>
            <kw>PGM</kw>
            <kw>pragmatic general multicast</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-speakman-pgm-spec-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3208</errata-url>
        <doi>10.17487/RFC3208</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>LSP</kw>
            <kw>label switched paths</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-rsvp-lsp-tunnel-09</draft>
        <updated-by>
            <doc-id>RFC3936</doc-id>
            <doc-id>RFC4420</doc-id>
            <doc-id>RFC4874</doc-id>
            <doc-id>RFC5151</doc-id>
            <doc-id>RFC5420</doc-id>
            <doc-id>RFC5711</doc-id>
            <doc-id>RFC6780</doc-id>
            <doc-id>RFC6790</doc-id>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3209</errata-url>
        <doi>10.17487/RFC3209</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>label</kw>
            <kw>switched</kw>
            <kw>paths</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-rsvp-tunnel-applicability-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3210</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3211</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>CR-LSPs</kw>
            <kw>constraint-based routed Label Switched Path</kw>
            <kw>LDP</kw>
            <kw>Label Distribution Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-cr-ldp-06</draft>
        <updated-by>
            <doc-id>RFC3468</doc-id>
            <doc-id>RFC7358</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3212</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>constraint-based</kw>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-crldp-applic-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3213</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>LSP</kw>
            <kw>label switching protocol</kw>
            <kw>CR-LDP</kw>
            <kw>constraint-based routed label switched paths</kw>
            <kw>distribution</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-crlsp-modify-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3214</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>78</page-count>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-ldp-state-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3215</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-sming-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sming</wg_acronym>
        <doi>10.17487/RFC3216</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>algorithm</kw>
            <kw>data encryption standard</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-key-wrap-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3217</errata-url>
        <doi>10.17487/RFC3217</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>cryptographic</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>This memo describes a strategy for resisting the Million Message Attack.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-smime-pkcs1-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3218</errata-url>
        <doi>10.17487/RFC3218</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>TRIP</kw>
            <kw>Telephony Routing over IP</kw>
            <kw>inter-administrative</kw>
            <kw>BGP</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-iptel-trip-09</draft>
        <updated-by>
            <doc-id>RFC8602</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3219</errata-url>
        <doi>10.17487/RFC3219</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>98</page-count>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3220</errata-url>
        <doi>10.17487/RFC3220</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-bgparch-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3221</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>routing table</kw>
            <kw>benchmark</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-fib-term-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC3222</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
            <kw>SVRLOC</kw>
            <kw>Service Location Protocol</kw>
            <kw>opaque</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <updates>
            <doc-id>RFC2608</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3224</errata-url>
        <doi>10.17487/RFC3224</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>domain name system security extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3225</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>domain name system security extensions</kw>
            <kw>space</kw>
            <kw>security</kw>
            <kw>extensions</kw>
            <kw>EDNS0</kw>
            <kw>Extension Mechanisms for DNSEx</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3226</errata-url>
        <doi>10.17487/RFC3226</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>security</kw>
            <kw>incident</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-grip-prot-evidence-05</draft>
        <is-also>
            <doc-id>BCP0055</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3227</errata-url>
        <doi>10.17487/RFC3227</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-magma-igmp-iana-01</draft>
        <obsoleted-by>
            <doc-id>RFC9778</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <doi>10.17487/RFC3228</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
        </keywords>
        <abstract><p>This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mogul-http-delta-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3229</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-mogul-http-digest-05</draft>
        <obsoleted-by>
            <doc-id>RFC9530</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3230</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC3231</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC1700</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3232</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3233</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>router</kw>
            <kw>data</kw>
            <kw>path</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-carpenter-midtax-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3234</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NAPT</kw>
            <kw>ALG</kw>
            <kw>firewall</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nat-app-guide-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nat</wg_acronym>
        <doi>10.17487/RFC3235</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-baker-xhtml-media-reg-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3236</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>rserpool</kw>
            <kw>application</kw>
        </keywords>
        <abstract><p>This document defines a basic set of requirements for reliable server pooling.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-reqts-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC3237</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>OPES</kw>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-opes-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3238</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>object</kw>
            <kw>device</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipp-ops-admin-req-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC3239</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-dicom-media-type-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3240</errata-url>
        <doi>10.17487/RFC3240</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>Robust Header Compression</kw>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>datagram</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rohc-over-ppp-04</draft>
        <updates>
            <doc-id>RFC1332</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4815</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3241</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>RObust Header Compression</kw>
            <kw> IP</kw>
            <kw>internet protocol</kw>
            <kw>UDP</kw>
            <kw>user datagram protocol</kw>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>application</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rohc-rtp-lla-03</draft>
        <obsoleted-by>
            <doc-id>RFC4362</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3242</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-rohc-rtp-0-byte-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3243</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>security</kw>
            <kw>message</kw>
            <kw>codes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-trostle-win2k-cat-kerberos-set-passwd-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3244</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>ARPA</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-itu-enum-notes-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3245</errata-url>
        <doi>10.17487/RFC3245</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PHB</kw>
            <kw>per-hop behavior</kw>
            <kw>expedited forwarding</kw>
            <kw>differentiated services</kw>
            <kw>delay</kw>
            <kw>jitter</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC3246</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>differentiated services</kw>
            <kw>fifo</kw>
            <kw>fair queuing</kw>
            <kw>delay</kw>
            <kw>jitter</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-diffserv-ef-supplemental-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3247</errata-url>
        <doi>10.17487/RFC3247</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>per hop behavior</kw>
            <kw>phb</kw>
            <kw>expedited forwarding</kw>
            <kw>ef</kw>
            <kw>db</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-diffserv-efresolve-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC3248</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-fax-implementers-guide-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3249</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3250</doi>
    </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>1</day>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bala-mplamps-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3251</doi>
    </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>1</day>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>bloat</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3252</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>118</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>clients</kw>
            <kw>label</kw>
            <kw>configuration</kw>
            <kw>management</kw>
            <kw>WebDAV</kw>
            <kw>Web Distributed Authoring and Versioning</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-deltav-versioning-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>deltav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3253</errata-url>
        <doi>10.17487/RFC3253</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>lightweight</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-alvestrand-directory-defs-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3254</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>Point-to-Point Protocol</kw>
            <kw>SONET/SDH</kw>
            <kw>Synchronous Optical NETwork/Synchronous Digital Hierarchy</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pppext-posvcholo-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3255</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DOCSIS</kw>
            <kw>Data-Over-Cable Service Interface Specification</kw>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
        </keywords>
        <abstract><p>This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-agentoptions-device-class-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3256</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-sigtran-sctp-applicability-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3257</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>network</kw>
            <kw>topology</kw>
            <kw>latency</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnsop-hardie-shared-root-server-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC3258</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>mbus</kw>
            <kw>message</kw>
            <kw>ip</kw>
            <kw>multicast</kw>
            <kw>addressing</kw>
            <kw>transport</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mmusic-mbus-transport-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC3259</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DIFFSRV</kw>
            <kw>scalability</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3260</errata-url>
        <doi>10.17487/RFC3260</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>269</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>application-layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
            <doc-id>RFC4320</doc-id>
            <doc-id>RFC4916</doc-id>
            <doc-id>RFC5393</doc-id>
            <doc-id>RFC5621</doc-id>
            <doc-id>RFC5626</doc-id>
            <doc-id>RFC5630</doc-id>
            <doc-id>RFC5922</doc-id>
            <doc-id>RFC5954</doc-id>
            <doc-id>RFC6026</doc-id>
            <doc-id>RFC6141</doc-id>
            <doc-id>RFC6665</doc-id>
            <doc-id>RFC6878</doc-id>
            <doc-id>RFC7462</doc-id>
            <doc-id>RFC7463</doc-id>
            <doc-id>RFC8217</doc-id>
            <doc-id>RFC8591</doc-id>
            <doc-id>RFC8760</doc-id>
            <doc-id>RFC8898</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3261</errata-url>
        <doi>10.17487/RFC3261</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>application-layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3262</errata-url>
        <doi>10.17487/RFC3262</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>application-layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-srv-06</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7984</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3263</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>application-layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-offer-answer-02</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6157</doc-id>
            <doc-id>RFC8843</doc-id>
            <doc-id>RFC9143</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3264</errata-url>
        <doi>10.17487/RFC3264</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>application-layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-events-05</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6665</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5367</doc-id>
            <doc-id>RFC5727</doc-id>
            <doc-id>RFC6446</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3265</errata-url>
        <doi>10.17487/RFC3265</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>internet addresses syntax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-ipv6-03</draft>
        <obsoleted-by>
            <doc-id>RFC4566</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2327</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3266</errata-url>
        <doi>10.17487/RFC3266</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-Time Transport Protocol</kw>
            <kw>Adaptive Multi-Rate</kw>
            <kw>AMR</kw>
            <kw>Adaptive Multi-Rate Wideband</kw>
            <kw>AMR-WB</kw>
            <kw> interoperate</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-amr-13</draft>
        <obsoleted-by>
            <doc-id>RFC4867</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3267</errata-url>
        <doi>10.17487/RFC3267</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>AES</kw>
            <kw>Advanced Encryption Standard</kw>
            <kw>TLS</kw>
            <kw>Transport Layer Security</kw>
            <kw>idea</kw>
            <kw>international data algorithm</kw>
            <kw>symmetric</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tls-ciphersuite-06</draft>
        <obsoleted-by>
            <doc-id>RFC5246</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC3268</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>definitions</kw>
            <kw>operation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-author-guidelines-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3269</doi>
    </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>
            <title>Editor</title>
        </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Multi-Protocol Label Switching</kw>
            <kw>diff-serv</kw>
            <kw>Differentiated Services</kw>
            <kw>BA</kw>
            <kw>behaviour aggregate</kw>
            <kw>LSP</kw>
            <kw>label switched paths</kw>
        </keywords>
        <abstract><p>This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-diff-ext-09</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3270</errata-url>
        <doi>10.17487/RFC3270</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-isoc-internet-for-everyone-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3271</errata-url>
        <doi>10.17487/RFC3271</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>te</kw>
            <kw>ip</kw>
            <kw>networks</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tewg-principles-02</draft>
        <obsoleted-by>
            <doc-id>RFC9522</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3272</errata-url>
        <doi>10.17487/RFC3272</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>rmon</kw>
            <kw>Remote Network Monitoring</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>high speed networks</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-hcrmon-10</draft>
        <updated-by>
            <doc-id>RFC4502</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3273</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>Cryptographic Message Syntax</kw>
            <kw>content info type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-compression-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3274</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>xmldsig</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3275</errata-url>
        <doi>10.17487/RFC3275</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>interfaces</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-adslmib-hdsl2-12</draft>
        <obsoleted-by>
            <doc-id>RFC4319</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <doi>10.17487/RFC3276</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>router</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-transient-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3277</errata-url>
        <doi>10.17487/RFC3277</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>public key</kw>
            <kw>digital signatures</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-smime-ecc-06</draft>
        <obsoleted-by>
            <doc-id>RFC5753</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3278</errata-url>
        <doi>10.17487/RFC3278</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>ASN.1</kw>
            <kw>X.509</kw>
            <kw>PKI</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>CRL</kw>
            <kw>Certificate Revocation List</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-ipki-pkalgs-05</draft>
        <updated-by>
            <doc-id>RFC4055</doc-id>
            <doc-id>RFC4491</doc-id>
            <doc-id>RFC5480</doc-id>
            <doc-id>RFC5758</doc-id>
            <doc-id>RFC8692</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3279</errata-url>
        <doi>10.17487/RFC3279</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>129</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>PKI</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>CRL</kw>
            <kw>Certificate Revocation List</kw>
        </keywords>
        <abstract><p>This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-new-part1-12</draft>
        <obsoletes>
            <doc-id>RFC2459</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5280</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4325</doc-id>
            <doc-id>RFC4630</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3280</errata-url>
        <doi>10.17487/RFC3280</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>electronic mail</kw>
            <kw>email</kw>
            <kw>ipsec</kw>
            <kw>www</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-ac509prof-09</draft>
        <obsoleted-by>
            <doc-id>RFC5755</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3281</errata-url>
        <doi>10.17487/RFC3281</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Content-language</kw>
            <kw>Accept-Language</kw>
            <kw>header</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3282</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>scheduling systems</kw>
            <kw>cap</kw>
            <kw>calendar access protocool</kw>
            <kw>itip</kw>
            <kw>imip</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-calsch-inetcal-guide-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsch</wg_acronym>
        <doi>10.17487/RFC3283</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>VCDIFF</kw>
            <kw>transport</kw>
            <kw>portable</kw>
            <kw>at&amp;t</kw>
            <kw>encoding</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-korn-vcdiff-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3284</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-hain-msword-template-04</draft>
        <obsoleted-by>
            <doc-id>RFC5385</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3285</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>telephony</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ong-sigtran-sctpover-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3286</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>120</page-count>
        <keywords>
            <kw>rmon</kw>
            <kw>Remote Monitoring</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>diffserv</kw>
            <kw>Differentiated Services</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-dsmon-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3287</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>binding</kw>
            <kw>markup language</kw>
            <kw>xml</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-etal-beep-soap-06</draft>
        <obsoleted-by>
            <doc-id>RFC4227</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3288</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>116</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>Management Information Base</kw>
            <kw>diffserv</kw>
            <kw>Differentiated Services Architecture</kw>
            <kw>router</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-diffserv-mib-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3289</errata-url>
        <doi>10.17487/RFC3289</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>differentiated services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-diffserv-model-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC3290</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>tc</kw>
            <kw>textual conventions</kw>
            <kw>mib</kw>
            <kw>layer</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC3291</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>137</page-count>
        <keywords>
            <kw>GSMP</kw>
            <kw>general switch label protocol</kw>
            <kw>unicast</kw>
            <kw>multicast</kw>
            <kw>qos</kw>
            <kw>quality of service</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-gsmp-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>gsmp</wg_acronym>
        <doi>10.17487/RFC3292</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>GSMP</kw>
            <kw>General Switch Management Protocol</kw>
            <kw>ATM</kw>
            <kw>Asynchronous Transfer Mode</kw>
            <kw>TCP</kw>
            <kw>Transmission Control Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-gsmp-encaps-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>gsmp</wg_acronym>
        <doi>10.17487/RFC3293</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-gsmp-applicability-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>gsmp</wg_acronym>
        <doi>10.17487/RFC3294</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>controller</kw>
            <kw>gsmp-mib</kw>
            <kw>General Switch Management Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-gsmp-mib-07</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>gsmp</wg_acronym>
        <doi>10.17487/RFC3295</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>schema</kw>
            <kw>elements</kw>
            <kw>description</kw>
            <kw>formats</kw>
        </keywords>
        <abstract><p>This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-namedref-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3296</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>content</kw>
            <kw>negotiation</kw>
            <kw>facsimile</kw>
        </keywords>
        <abstract><p>This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fax-content-negotiation-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3297</errata-url>
        <doi>10.17487/RFC3297</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>support</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-spirits-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>spirits</wg_acronym>
        <doi>10.17487/RFC3298</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3299</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <obsoletes>
            <doc-id>RFC3000</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3600</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3300</errata-url>
        <doi>10.17487/RFC3300</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer Two Tunneling Protocol</kw>
        </keywords>
        <draft>draft-ietf-l2tpext-atmext-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3301</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TIFF</kw>
            <kw>Tag Image File Format</kw>
            <kw>MIME</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
        </keywords>
        <draft>draft-ietf-fax-tiff-regbis-05</draft>
        <obsoletes>
            <doc-id>RFC2302</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3302</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>midcom</kw>
        </keywords>
        <draft>draft-ietf-midcom-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <doi>10.17487/RFC3303</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>nat</kw>
            <kw>network address protocol</kw>
            <kw>firewall middleboxes</kw>
        </keywords>
        <draft>draft-ietf-midcom-requirements-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3304</errata-url>
        <doi>10.17487/RFC3304</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet engineering task force</kw>
        </keywords>
        <draft>draft-mealling-uri-ig-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3305</errata-url>
        <doi>10.17487/RFC3305</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>multicast</kw>
        </keywords>
        <draft>draft-ietf-ipngwg-uni-based-mcast-03</draft>
        <updated-by>
            <doc-id>RFC3956</doc-id>
            <doc-id>RFC4489</doc-id>
            <doc-id>RFC7371</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3306</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>multicast</kw>
        </keywords>
        <draft>draft-ietf-malloc-ipv6-guide-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC3307</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer Two Tunneling Protocol</kw>
            <kw>per hop behavior</kw>
            <kw>phb</kw>
            <kw>diffserv</kw>
            <kw>Differentiated Services Extension</kw>
        </keywords>
        <draft>draft-ietf-l2tpext-ds-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3308</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>adler-32</kw>
            <kw>checksum</kw>
            <kw>error detection</kw>
        </keywords>
        <draft>draft-ietf-tsvwg-sctpcsum-07</draft>
        <obsoleted-by>
            <doc-id>RFC4960</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2960</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3309</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>one-time password generation mechanism</kw>
            <kw>umts</kw>
            <kw>universal mobile telecommunications system</kw>
        </keywords>
        <draft>draft-ietf-sip-digest-aka-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3310</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>parameters</kw>
            <kw>media streams</kw>
        </keywords>
        <draft>draft-ietf-sip-update-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3311</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>precondition</kw>
        </keywords>
        <draft>draft-ietf-sip-manyfolks-resource-07</draft>
        <updated-by>
            <doc-id>RFC4032</doc-id>
            <doc-id>RFC5027</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3312</errata-url>
        <doi>10.17487/RFC3312</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
        </keywords>
        <draft>draft-ietf-sip-call-auth-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3313</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <draft>draft-ietf-ipv6-3gpp-recommend-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3314</errata-url>
        <doi>10.17487/RFC3314</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Dynamic Host Configuration Protocol for IPv6</kw>
            <kw>internet protocol</kw>
            <kw>parameters</kw>
            <kw>addresses</kw>
        </keywords>
        <draft>draft-ietf-dhc-dhcpv6-28</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4361</doc-id>
            <doc-id>RFC5494</doc-id>
            <doc-id>RFC6221</doc-id>
            <doc-id>RFC6422</doc-id>
            <doc-id>RFC6644</doc-id>
            <doc-id>RFC7083</doc-id>
            <doc-id>RFC7227</doc-id>
            <doc-id>RFC7283</doc-id>
            <doc-id>RFC7550</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3315</errata-url>
        <doi>10.17487/RFC3315</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>links</kw>
            <kw>bandwidth</kw>
        </keywords>
        <draft>draft-ietf-ipv6-cellular-host-03</draft>
        <obsoleted-by>
            <doc-id>RFC7066</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3316</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>pib</kw>
            <kw>differentiated services architecture</kw>
        </keywords>
        <draft>draft-ietf-diffserv-pib-08</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>diffserv</wg_acronym>
        <doi>10.17487/RFC3317</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <abstract><p>This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning.</p><p> Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).</p><p> One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.</p><p> As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each.</p></abstract>
        <draft>draft-ietf-rap-frameworkpib-09</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3318</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>outbound proxy servers</kw>
        </keywords>
        <draft>draft-ietf-sip-dhcpv6-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3319</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>udvm</kw>
            <kw>universal decompressor virtual machine</kw>
            <kw>SigComp</kw>
            <kw>Signaling Compression</kw>
        </keywords>
        <draft>draft-ietf-rohc-sigcomp-07</draft>
        <updated-by>
            <doc-id>RFC4896</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3320</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>udvm</kw>
            <kw>universal decompressor virtual machine</kw>
            <kw>SigComp</kw>
            <kw>Signaling Compression</kw>
        </keywords>
        <draft>draft-ietf-rohc-sigcomp-extended-04</draft>
        <updated-by>
            <doc-id>RFC4896</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3321</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>wireless</kw>
            <kw>cellular</kw>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
            <kw>SigComp</kw>
            <kw>Signaling Compression</kw>
        </keywords>
        <draft>draft-ietf-rohc-signaling-req-assump-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3322</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>privacy service</kw>
        </keywords>
        <draft>draft-ietf-sip-privacy-general-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3323</errata-url>
        <doi>10.17487/RFC3323</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>session initiation protocol</kw>
            <kw>sip</kw>
            <kw>ua</kw>
            <kw>user agent</kw>
        </keywords>
        <draft>draft-ietf-sipping-nai-reqs-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3324</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>trust domain</kw>
        </keywords>
        <draft>draft-ietf-sip-asserted-identity-01</draft>
        <updated-by>
            <doc-id>RFC5876</doc-id>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3325</errata-url>
        <doi>10.17487/RFC3325</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>heterogeneous error response forking problem</kw>
            <kw>herfp</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-reason-01</draft>
        <updated-by>
            <doc-id>RFC8606</doc-id>
            <doc-id>RFC9366</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3326</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>3gpp</kw>
            <kw>register</kw>
            <kw>contact</kw>
            <kw>path</kw>
            <kw>registrar</kw>
            <kw>user agent</kw>
            <kw>ua</kw>
        </keywords>
        <draft>draft-willis-sip-path-08</draft>
        <updated-by>
            <doc-id>RFC5626</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3327</errata-url>
        <doi>10.17487/RFC3327</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>UA</kw>
            <kw>user agent</kw>
        </keywords>
        <draft>draft-ietf-sip-sec-agree-05</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3329</errata-url>
        <doi>10.17487/RFC3329</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>space assignments</kw>
        </keywords>
        <draft>draft-iana-special-ipv4-05</draft>
        <obsoleted-by>
            <doc-id>RFC5735</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3330</errata-url>
        <doi>10.17487/RFC3330</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <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>draft-ietf-sigtran-m2ua-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3331</errata-url>
        <doi>10.17487/RFC3331</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>120</page-count>
        <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>draft-ietf-sigtran-m3ua-12</draft>
        <obsoleted-by>
            <doc-id>RFC4666</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3332</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3333</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>measurement</kw>
            <kw>metering</kw>
            <kw>meter configuration</kw>
            <kw>qos auditing</kw>
            <kw>aaa</kw>
            <kw>architecture</kw>
            <kw>inter-domain accounting</kw>
        </keywords>
        <draft>draft-irtf-aaaarch-pol-acct-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3334</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>edi</kw>
            <kw>Electronic Data Interchange-Internet Integration</kw>
        </keywords>
        <draft>draft-ietf-ediint-as1-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ediint</wg_acronym>
        <doi>10.17487/RFC3335</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>atm</kw>
            <kw>Asynchronous Transfer Mode</kw>
            <kw>aal2</kw>
            <kw>datagram</kw>
            <kw>packets</kw>
        </keywords>
        <draft>draft-ietf-pppext-ppp-over-aal2-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3336</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>point-to-point protocol</kw>
            <kw>ATM</kw>
            <kw>Asynchronous Transfer Mode Adaptation Layer 2</kw>
            <kw>aal2</kw>
            <kw>encapsulation</kw>
        </keywords>
        <draft>draft-ietf-pppext-ppp-over-aal2-class-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3337</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>BIA</kw>
            <kw>Bump-in-the-API</kw>
        </keywords>
        <draft>draft-ietf-ngtrans-bia-05</draft>
        <obsoleted-by>
            <doc-id>RFC6535</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ngtrans</wg_acronym>
        <doi>10.17487/RFC3338</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Timestamps</kw>
            <kw>gregorian calendar</kw>
            <kw>iso</kw>
            <kw>International Organization for Standardization</kw>
        </keywords>
        <abstract><p>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</p></abstract>
        <draft>draft-ietf-impp-datetime-05</draft>
        <updated-by>
            <doc-id>RFC9557</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3339</errata-url>
        <doi>10.17487/RFC3339</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>APEX</kw>
            <kw>Application Exchange Core</kw>
        </keywords>
        <draft>draft-ietf-apex-core-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>apex</wg_acronym>
        <doi>10.17487/RFC3340</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>APEX</kw>
            <kw>Application Exchange</kw>
        </keywords>
        <draft>draft-ietf-apex-access-08</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>apex</wg_acronym>
        <doi>10.17487/RFC3341</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>APEX</kw>
            <kw>Application Exchange</kw>
            <kw>datagram</kw>
            <kw>service</kw>
            <kw>core</kw>
            <kw>relaying</kw>
            <kw>mesh</kw>
        </keywords>
        <draft>draft-ietf-apex-party-04</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>apex</wg_acronym>
        <doi>10.17487/RFC3342</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>APEX</kw>
            <kw>Application Exchange</kw>
            <kw>endpoint</kw>
        </keywords>
        <draft>draft-ietf-apex-presence-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>apex</wg_acronym>
        <doi>10.17487/RFC3343</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet Protocol Mobility Support for IPv4</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC3220</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5944</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4636</doc-id>
            <doc-id>RFC4721</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3344</errata-url>
        <doi>10.17487/RFC3344</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>idr</kw>
            <kw>ibgp</kw>
        </keywords>
        <draft>draft-ietf-idr-route-oscillation-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3345</errata-url>
        <doi>10.17487/RFC3345</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>te</kw>
        </keywords>
        <draft>draft-ietf-tewg-te-applicability-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC3346</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>iSCSI</kw>
            <kw>Small Computer Systems Interface</kw>
            <kw>TCP</kw>
            <kw>Transmission Control Protocol</kw>
            <kw>storage</kw>
            <kw>fibre channel</kw>
        </keywords>
        <draft>draft-ietf-ips-iscsi-reqmts-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3347</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>children</kw>
        </keywords>
        <draft>draft-gahrns-imap-child-mailbox-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3348</errata-url>
        <doi>10.17487/RFC3348</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>beep</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3349</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3350</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>relay service</kw>
            <kw>transcoding service</kw>
            <kw>textphone</kw>
        </keywords>
        <draft>draft-ietf-sipping-deaf-req-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3351</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>CLDAP</kw>
            <kw>CLDAP</kw>
            <kw>Presentation</kw>
            <kw>Address</kw>
            <kw>Application</kw>
            <kw>Entity</kw>
            <kw>Title</kw>
        </keywords>
        <draft>draft-zeilenga-cldap-02</draft>
        <obsoletes>
            <doc-id>RFC1798</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3352</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>inrternet protocol</kw>
            <kw>l2</kw>
            <kw>multicast routing protocoln</kw>
        </keywords>
        <draft>draft-ietf-mpls-multicast-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3353</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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>draft-ietf-trade-iotp2-req-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC3354</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer Two Tunneling Protocol</kw>
            <kw>link</kw>
            <kw>dial-up server</kw>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>adaptation layer</kw>
        </keywords>
        <draft>draft-ietf-l2tpext-l2tp-atm-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3355</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>society</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <draft>draft-fishman-2436bis-02</draft>
        <obsoletes>
            <doc-id>RFC2436</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6756</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3356</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>packets</kw>
            <kw>voice</kw>
            <kw>video</kw>
            <kw>stream</kw>
        </keywords>
        <draft>draft-ietf-ippm-loss-pattern-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC3357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3358</doc-id>
        <title>Optional Checksums in Intermediate System to Intermediate System (ISIS)</title>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>type</kw>
            <kw>length</kw>
            <kw>value</kw>
            <kw>complete sequence number</kw>
            <kw>partial data</kw>
        </keywords>
        <draft>draft-ietf-isis-wg-snp-checksum-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3358</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>is-is</kw>
            <kw>igp</kw>
            <kw>osi</kw>
            <kw>complete sequence number</kw>
            <kw>partial data</kw>
        </keywords>
        <draft>draft-ietf-isis-wg-tlv-codepoints-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3359</errata-url>
        <doi>10.17487/RFC3359</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>rst</kw>
            <kw>bit</kw>
            <kw>connection</kw>
        </keywords>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3360</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>proxy servers</kw>
        </keywords>
        <draft>draft-ietf-sip-dhcp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3361</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>T.38</kw>
            <kw>Real-time Facsimile</kw>
            <kw>MIME</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>image/t38</kw>
        </keywords>
        <draft>draft-parsons-itu-t38-reg-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3362</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>reverse mapping</kw>
            <kw>label binary</kw>
        </keywords>
        <draft>draft-ietf-dnsext-ipv6-addresses-02</draft>
        <updates>
            <doc-id>RFC2673</doc-id>
            <doc-id>RFC2874</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6672</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3363</errata-url>
        <doi>10.17487/RFC3363</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>reverse mapping</kw>
            <kw>rrs</kw>
            <kw>resource records</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3364</errata-url>
        <doi>10.17487/RFC3364</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ietf</kw>
        </keywords>
        <draft>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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3365</errata-url>
        <doi>10.17487/RFC3365</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>tcp/ip</kw>
            <kw>subnetworks</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <doi>10.17487/RFC3366</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>CNRP</kw>
            <kw>Common Name Resolution Protocol</kw>
            <kw>unique resource locators</kw>
            <kw>client applications</kw>
        </keywords>
        <draft>draft-ietf-cnrp-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3367</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>URI</kw>
            <kw>uniform resource identifier</kw>
            <kw>CNRP</kw>
            <kw>Common Name Resolution Protocol</kw>
        </keywords>
        <draft>draft-ietf-cnrp-uri-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3368</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3369</errata-url>
        <doi>10.17487/RFC3369</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>Cryptographic Message Syntax</kw>
            <kw>algorithms</kw>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <draft>draft-ietf-smime-cmsalg-08</draft>
        <obsoletes>
            <doc-id>RFC2630</doc-id>
            <doc-id>RFC3211</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5754</doc-id>
            <doc-id>RFC8702</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3370</errata-url>
        <doi>10.17487/RFC3370</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer Two Tunneling Protocol</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <draft>draft-ietf-l2tpext-l2tp-mib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3371</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>pstn</kw>
            <kw>public switch telephone network</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3372</errata-url>
        <doi>10.17487/RFC3372</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>links</kw>
            <kw>handshake</kw>
        </keywords>
        <draft>draft-ietf-isis-3way-06</draft>
        <obsoleted-by>
            <doc-id>RFC5303</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3373</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>aaa</kw>
            <kw>qos</kw>
            <kw>authentication authorization accounting</kw>
            <kw>quality of service</kw>
            <kw>header compression</kw>
        </keywords>
        <draft>draft-ietf-seamoby-context-transfer-problem-stat-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC3374</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>rrp</kw>
            <kw>client server</kw>
            <kw>domain names</kw>
        </keywords>
        <draft>draft-ietf-provreg-grrp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <doi>10.17487/RFC3375</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>IGMP</kw>
            <kw>Internet Group Management Protocol</kw>
            <kw>multicast</kw>
            <kw>routing</kw>
            <kw>IP</kw>
            <kw>Internet Protocol</kw>
        </keywords>
        <draft>draft-ietf-idmr-igmp-v3-11</draft>
        <obsoleted-by>
            <doc-id>RFC9776</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2236</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4604</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idmr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3376</errata-url>
        <doi>10.17487/RFC3376</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ldap</kw>
            <kw>ldapv3</kw>
        </keywords>
        <draft>draft-ietf-ldapbis-ldapv3-ts-01</draft>
        <obsoleted-by>
            <doc-id>RFC4510</doc-id>
        </obsoleted-by>
        <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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3377</errata-url>
        <doi>10.17487/RFC3377</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>ip 97</kw>
        </keywords>
        <draft>draft-housley-etherip-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3378</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>dpv</kw>
            <kw>Delegated Path Validation</kw>
            <kw>dpd</kw>
            <kw>Delegated Path Discovery</kw>
            <kw>public key</kw>
            <kw>certificates</kw>
        </keywords>
        <draft>draft-ietf-pkix-dpv-dpd-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC3379</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3380</errata-url>
        <doi>10.17487/RFC3380</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
        </keywords>
        <draft>draft-ietf-ipp-job-prog-02</draft>
        <obsoleted-by>
            <doc-id>RFC8011</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2910</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3381</errata-url>
        <doi>10.17487/RFC3381</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
        </keywords>
        <draft>draft-ietf-ipp-collection-05</draft>
        <obsoleted-by>
            <doc-id>RFC8010</doc-id>
            <doc-id>RFC8011</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2910</doc-id>
            <doc-id>RFC2911</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3382</errata-url>
        <doi>10.17487/RFC3382</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>guidelines</kw>
            <kw>extensible values</kw>
        </keywords>
        <draft>draft-ietf-ldapbis-iana-09</draft>
        <obsoleted-by>
            <doc-id>RFC4520</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <doi>10.17487/RFC3383</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ldapv3</kw>
            <kw>data interoperability</kw>
            <kw>synchronization</kw>
            <kw>multi-master</kw>
        </keywords>
        <draft>draft-ietf-ldup-replica-req-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldup</wg_acronym>
        <doi>10.17487/RFC3384</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>error detection code</kw>
        </keywords>
        <draft>draft-sheinwald-iscsi-crc-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3385</errata-url>
        <doi>10.17487/RFC3385</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>service</kw>
            <kw>provider</kw>
            <kw>packet networks</kw>
            <kw>protection</kw>
            <kw>restoration</kw>
            <kw>recovery</kw>
        </keywords>
        <draft>draft-ietf-tewg-restore-hierarchy-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC3386</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>packts</kw>
            <kw>fuel-service</kw>
        </keywords>
        <draft>draft-irtf-smrg-ipsmf-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3387</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <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>draft-ietf-mmusic-fid-06</draft>
        <obsoleted-by>
            <doc-id>RFC5888</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC3388</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-time Transport Protocol</kw>
            <kw>CN</kw>
            <kw>Comfort Noise</kw>
            <kw>codecs</kw>
            <kw>audio</kw>
            <kw>multimedia</kw>
        </keywords>
        <draft>draft-ietf-avt-rtp-cn-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3389</errata-url>
        <doi>10.17487/RFC3389</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3390</errata-url>
        <doi>10.17487/RFC3390</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>multipurpose internet mail extensions</kw>
            <kw>media type</kw>
        </keywords>
        <draft>draft-herriot-application-multiplexed-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3391</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <draft>draft-ietf-idr-rfc2842bis-02</draft>
        <obsoletes>
            <doc-id>RFC2842</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5492</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC3392</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>IP Performance Metrics</kw>
            <kw>internet protocol</kw>
            <kw>ipdv</kw>
            <kw>IP Packet Delay Variation</kw>
        </keywords>
        <draft>draft-ietf-ippm-ipdv-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3393</errata-url>
        <doi>10.17487/RFC3393</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>security</kw>
        </keywords>
        <draft>draft-ietf-smime-aes-keywrap-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3394</errata-url>
        <doi>10.17487/RFC3394</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>Remote Network Monitoring</kw>
            <kw>management information base</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3395</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DHCPv4</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>octet</kw>
            <kw>packet</kw>
            <kw>code</kw>
        </keywords>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3396</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>dns</kw>
            <kw>Domain Name System</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <draft>draft-aboba-dhc-domsearch-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3397</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>ISDN</kw>
            <kw>Integrated Services Digital Network</kw>
            <kw>ISUP</kw>
            <kw>User Part</kw>
            <kw>signaling system no. 7</kw>
            <kw>ss7</kw>
            <kw>pstn</kw>
            <kw>public switched telephone network</kw>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <draft>draft-ietf-sipping-isup-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3398</errata-url>
        <doi>10.17487/RFC3398</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3399</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3401</errata-url>
        <doi>10.17487/RFC3401</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NAPTR</kw>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
            <kw>Resource Record</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3402</errata-url>
        <doi>10.17487/RFC3402</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>NAPTR</kw>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
            <kw>Resource Record</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3403</errata-url>
        <doi>10.17487/RFC3403</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>NAPTR</kw>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
            <kw>Resource Record</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3404</errata-url>
        <doi>10.17487/RFC3404</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>uniform resource identifiers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-urn-net-procedures-11</draft>
        <updated-by>
            <doc-id>RFC8958</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0065</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3405</errata-url>
        <doi>10.17487/RFC3405</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>namespaces</kw>
            <kw>applications</kw>
            <kw>structure</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-urn-rfc2611bis-04</draft>
        <obsoletes>
            <doc-id>RFC2611</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8141</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>urn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3406</errata-url>
        <doi>10.17487/RFC3406</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SDPng</kw>
            <kw>Session Description Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-andreasen-mmusic-sdp-simcap-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3407</errata-url>
        <doi>10.17487/RFC3407</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>RObust Header Compression</kw>
            <kw>single-octet</kw>
            <kw>packet size</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rohc-rtp-lla-r-mode-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3408</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>rohc</kw>
            <kw>algorithms</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rohc-rtp-lower-layer-guidelines-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3409</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
            <kw>snmpv3</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-snmpv3-rfc2570bis-03</draft>
        <obsoletes>
            <doc-id>RFC2570</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3410</errata-url>
        <doi>10.17487/RFC3410</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>ARCH-SNMP</kw>
            <kw>Architecture</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-snmpv3-arch-v2-02</draft>
        <obsoletes>
            <doc-id>RFC2571</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5343</doc-id>
            <doc-id>RFC5590</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3411</errata-url>
        <doi>10.17487/RFC3411</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>MPD-SNMP</kw>
            <kw>Message Processing and Dispatching</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>processing</kw>
            <kw>models</kw>
            <kw>multiple</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-snmpv3-mpd-v2-02</draft>
        <obsoletes>
            <doc-id>RFC2572</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5590</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3412</errata-url>
        <doi>10.17487/RFC3412</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>SNMP-APP</kw>
            <kw>simple network management protocol</kw>
            <kw>applications</kw>
            <kw>proxy</kw>
            <kw>operations</kw>
            <kw>command</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3413</errata-url>
        <doi>10.17487/RFC3413</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>USM-SNMPV3</kw>
            <kw>User-based Security Model</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>message</kw>
            <kw>level</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-snmpv3-usm-v2-rfc2574bis-01</draft>
        <obsoletes>
            <doc-id>RFC2574</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5590</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3414</errata-url>
        <doi>10.17487/RFC3414</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>VACM-SNMP</kw>
            <kw>View-based Access Control Model</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3415</errata-url>
        <doi>10.17487/RFC3415</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>OPS-MIB</kw>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol Version 2</kw>
            <kw>Management Information Base</kw>
            <kw>operations</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3416</errata-url>
        <doi>10.17487/RFC3416</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TRANS-MIB</kw>
            <kw>Transport</kw>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol Version 2</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols.  This document obsoletes RFC 1906. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-snmpv3-update-transmap-08</draft>
        <obsoletes>
            <doc-id>RFC1906</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4789</doc-id>
            <doc-id>RFC5590</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC3417</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>SNMPv2-MIB</kw>
            <kw>Simple Network Management Protocol Version 2</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3418</errata-url>
        <doi>10.17487/RFC3418</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ops-taddress-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3419</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-sipfrag-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3420</errata-url>
        <doi>10.17487/RFC3420</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
            <kw>UA</kw>
            <kw>user agent</kw>
            <kw>URL</kw>
            <kw>Uniform Resource Locator</kw>
            <kw>service reply</kw>
            <kw>svrrply</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zhao-slp-customization-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3421</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>tunneling</kw>
            <kw>ethernet frames</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-okamoto-mac-over-mapos-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3422</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>data</kw>
            <kw>delivery</kw>
            <kw>message</kw>
            <kw>format</kw>
            <kw>template-based</kw>
            <kw>client/server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-kzhang-crane-protocol-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3423</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>nat</kw>
            <kw>middleboxes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-unsaf-considerations-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3424</errata-url>
        <doi>10.17487/RFC3424</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>dns lookups</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3425</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>internet architecture</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-considerations-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3426</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>sipping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-tsvarea-sipchange-03</draft>
        <obsoleted-by>
            <doc-id>RFC5727</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3968</doc-id>
            <doc-id>RFC3969</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3427</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>IM</kw>
            <kw>Instant Messaging</kw>
            <kw>message method</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-message-07</draft>
        <updated-by>
            <doc-id>RFC8591</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3428</errata-url>
        <doi>10.17487/RFC3428</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>reserved lavel values</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ohta-mpls-label-value-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3429</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>TCP</kw>
            <kw>Transmission Control Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-nmrg-snmp-tcp-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3430</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>sieve mail</kw>
            <kw>filtering language</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-segmuller-sieve-relation-02</draft>
        <obsoleted-by>
            <doc-id>RFC5231</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3431</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>cbr</kw>
            <kw>constant bit rate</kw>
            <kw>periodic sampling</kw>
            <kw>poisson sampling</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ippm-npmps-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC3432</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>physical sensors</kw>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-entmib-sensor-mib-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>entmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3433</errata-url>
        <doi>10.17487/RFC3433</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>RMON</kw>
            <kw>Remote Monitoring</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>counter64</kw>
            <kw>smiv2</kw>
            <kw>Structure of Management Information Version 2</kw>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-hc-alarm-mib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3434</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>210</page-count>
        <keywords>
            <kw>voice</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3435</errata-url>
        <doi>10.17487/RFC3435</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>Stream Control Transmission Protocol</kw>
            <kw>TLS</kw>
            <kw>Transport Layer Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-tls-over-sctp-00</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3436</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer-Two Tunneling Protocol</kw>
            <kw>LCP</kw>
            <kw>Link Control Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-l2tpext-link-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3437</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3438</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>IAB</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ymbk-arch-guidelines-03</draft>
        <updates>
            <doc-id>RFC1958</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3439</errata-url>
        <doi>10.17487/RFC3439</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network management protocol</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>ADSL</kw>
            <kw>asymmetric digital subscriber line</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-adslmib-adslext-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <doi>10.17487/RFC3440</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>connection</kw>
            <kw>codec profile</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-rajeshkumar-mgcp-atm-package-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3441</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3442</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>TTL</kw>
            <kw>Time To Live</kw>
            <kw>label stack encoding</kw>
            <kw>uniform model</kw>
            <kw>pipe model</kw>
            <kw>MPLS</kw>
            <kw>Multi-Protocol Label Switching</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-ttl-04</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3443</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>network management</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-nmrg-im-dm-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3444</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3445</errata-url>
        <doi>10.17487/RFC3445</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>sparse mode</kw>
            <kw>single shared-tree</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mboned-anycast-rp-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC3446</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>data</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-jonsson-pkcs1-v2dot1-00</draft>
        <obsoletes>
            <doc-id>RFC2437</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8017</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3447</errata-url>
        <doi>10.17487/RFC3447</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>TFRC</kw>
            <kw>TCP Friendly Rate Control</kw>
            <kw>congestion</kw>
            <kw>unicast</kw>
            <kw>streaming media</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-tfrc-05</draft>
        <obsoleted-by>
            <doc-id>RFC5348</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3448</errata-url>
        <doi>10.17487/RFC3448</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>links</kw>
            <kw>sender</kw>
            <kw>receiver</kw>
            <kw>ack</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <doi>10.17487/RFC3449</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>content</kw>
            <kw>delivery</kw>
            <kw>congestion</kw>
            <kw>control</kw>
            <kw>receivers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-pi-alc-08</draft>
        <obsoleted-by>
            <doc-id>RFC5775</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3450</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>LCT</kw>
            <kw>Layered Coding Transport</kw>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-bb-lct-04</draft>
        <obsoleted-by>
            <doc-id>RFC5651</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3451</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>Forward Error Correction</kw>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-07</draft>
        <obsoleted-by>
            <doc-id>RFC5052</doc-id>
            <doc-id>RFC5445</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3452</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ip</kw>
            <kw>internet protocol</kw>
            <kw>data transport</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-info-fec-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3453</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>unicode text</kw>
            <kw>internationalization</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-hoffman-stringprep-07</draft>
        <obsoleted-by>
            <doc-id>RFC7564</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3454</errata-url>
        <doi>10.17487/RFC3454</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-garcia-sipping-3gpp-p-headers-02</draft>
        <obsoleted-by>
            <doc-id>RFC7315</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3455</errata-url>
        <doi>10.17487/RFC3455</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DHCPv4</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>security</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-dhcp-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsra</wg_acronym>
        <doi>10.17487/RFC3456</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ipsra</kw>
            <kw>common remote access scenarios</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipsra-reqmts-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsra</wg_acronym>
        <doi>10.17487/RFC3457</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>user agent</kw>
            <kw>UA</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3458</errata-url>
        <doi>10.17487/RFC3458</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>Multi-purpose Internet Mail Extensions</kw>
            <kw>body parts</kw>
            <kw>content-disposition</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-vpim-cc-08</draft>
        <updates>
            <doc-id>RFC3204</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5621</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC3459</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>93</page-count>
        <keywords>
            <kw>PCIM</kw>
            <kw>Policy Core Information Model</kw>
            <kw>common</kw>
            <kw>schema</kw>
            <kw>object-oriented</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>policy</wg_acronym>
        <doi>10.17487/RFC3460</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>SMTP-DSN</kw>
            <kw>Simple Mail Transfer Protocol</kw>
            <kw>Delivery Status Notifications</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-moore-rfc1891bis-02</draft>
        <obsoletes>
            <doc-id>RFC1891</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3798</doc-id>
            <doc-id>RFC3885</doc-id>
            <doc-id>RFC5337</doc-id>
            <doc-id>RFC6533</doc-id>
            <doc-id>RFC8098</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3461</errata-url>
        <doi>10.17487/RFC3461</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>MIME-RPT</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>Report</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-vaudreuil-1892bis-02</draft>
        <obsoletes>
            <doc-id>RFC1892</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6522</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5337</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3462</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>EMS-CODE</kw>
            <kw>Enhanced Mail System Status Codes</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-vaudreuil-1893bis-03</draft>
        <obsoletes>
            <doc-id>RFC1893</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3886</doc-id>
            <doc-id>RFC4468</doc-id>
            <doc-id>RFC4865</doc-id>
            <doc-id>RFC4954</doc-id>
            <doc-id>RFC5248</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3463</errata-url>
        <doi>10.17487/RFC3463</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>DSN</kw>
            <kw>Delivery Status Notifications</kw>
            <kw>MIME</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>Content Type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-vaudreuil-1894bis-02</draft>
        <obsoletes>
            <doc-id>RFC1894</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4865</doc-id>
            <doc-id>RFC5337</doc-id>
            <doc-id>RFC6533</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3464</errata-url>
        <doi>10.17487/RFC3464</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>security performance</kw>
            <kw>ABC</kw>
            <kw>Appropriate Byte Counting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-allman-tcp-abc-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3465</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>distribution peering</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-cdi-model-02</draft>
        <obsoleted-by>
            <doc-id>RFC7336</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>cdi</wg_acronym>
        <doi>10.17487/RFC3466</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>history</kw>
            <kw>internationalization</kw>
            <kw>unicode</kw>
            <kw>ascii</kw>
            <kw>multilingual names</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-klensin-dns-role-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3467</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>rsvp-te</kw>
            <kw>ldp</kw>
            <kw>resource reservation protocol label distribution</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3468</errata-url>
        <doi>10.17487/RFC3468</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>routing traffic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mpls-recovery-frmwrk-08</draft>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3469</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>data</kw>
            <kw>documents</kw>
            <kw>structure</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hollenbeck-ietf-xml-guidelines-07</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0070</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3470</errata-url>
        <doi>10.17487/RFC3470</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>Generalized Multi-Protocol Label Switching</kw>
            <kw>SONET/SDH</kw>
            <kw>Synchronous Optical Network</kw>
            <kw>Synchronous Digital Hierarchy</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-generalized-signaling-09</draft>
        <updated-by>
            <doc-id>RFC4201</doc-id>
            <doc-id>RFC4328</doc-id>
            <doc-id>RFC4872</doc-id>
            <doc-id>RFC6002</doc-id>
            <doc-id>RFC6003</doc-id>
            <doc-id>RFC6205</doc-id>
            <doc-id>RFC7074</doc-id>
            <doc-id>RFC7699</doc-id>
            <doc-id>RFC8359</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3471</errata-url>
        <doi>10.17487/RFC3471</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>Generalized Multi-Protocol Label Switching</kw>
            <kw>SONET/SDH</kw>
            <kw>Synchronous Optical Network</kw>
            <kw>Synchronous Digital Hierarchy</kw>
            <kw>CR-LDP</kw>
            <kw>Constraint-based Routed Label Distribution Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-generalized-cr-ldp-07</draft>
        <updated-by>
            <doc-id>RFC3468</doc-id>
            <doc-id>RFC4201</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC3472</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>Generalized Multi-Protocol Label Switching</kw>
            <kw>SONET/SDH</kw>
            <kw>Synchronous Optical Network</kw>
            <kw>Synchronous Digital Hierarchy</kw>
            <kw>RSVP-TE</kw>
            <kw>Resource ReserVation Protocol</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-generalized-rsvp-te-09</draft>
        <updated-by>
            <doc-id>RFC4003</doc-id>
            <doc-id>RFC4201</doc-id>
            <doc-id>RFC4420</doc-id>
            <doc-id>RFC4783</doc-id>
            <doc-id>RFC4874</doc-id>
            <doc-id>RFC4873</doc-id>
            <doc-id>RFC4974</doc-id>
            <doc-id>RFC5063</doc-id>
            <doc-id>RFC5151</doc-id>
            <doc-id>RFC5420</doc-id>
            <doc-id>RFC6002</doc-id>
            <doc-id>RFC6003</doc-id>
            <doc-id>RFC6780</doc-id>
            <doc-id>RFC8359</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3473</errata-url>
        <doi>10.17487/RFC3473</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>sonet</kw>
            <kw>sdh</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-lin-ccamp-gmpls-ason-rsvpte-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3474</errata-url>
        <doi>10.17487/RFC3474</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>label switching protocol</kw>
            <kw>itu-t</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3475</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>oif</kw>
            <kw>optical interworking forum</kw>
            <kw>uni</kw>
            <kw>user network interface</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3476</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MPLS-TE</kw>
            <kw>Multi-Protocol Label Switching</kw>
            <kw>Traffic Engineering</kw>
            <kw>RSVP</kw>
            <kw>Resource ReSerVation Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-rsvp-unnum-08</draft>
        <updated-by>
            <doc-id>RFC6107</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3477</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>LDP</kw>
            <kw>Label Distribution Protocol</kw>
            <kw>MPLS</kw>
            <kw>Multi-Protocol Label Switching</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-ldp-restart-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3478</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>multiprotocol label switching</kw>
            <kw>LDP</kw>
            <kw>Label Distribution Protocol</kw>
            <kw>high availability restart</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-ldp-ft-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3479</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>multiprotocol label switching</kw>
            <kw>traffic engineering</kw>
            <kw>mpls-te</kw>
            <kw>Traffic Engineering</kw>
            <kw>CR-LDP</kw>
            <kw>Constraint-Routing Label Distribution Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3480</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>paths</kw>
            <kw>algorithm stacks</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <doi>10.17487/RFC3481</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>e.164</kw>
            <kw>telephony routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-enum-e164-gstn-np-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC3482</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>accounting</kw>
            <kw>policy decision</kw>
            <kw>point</kw>
            <kw>bdp</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rap-feedback-frwk-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3483</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>source</kw>
            <kw>address destination</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipv6-default-addr-select-09</draft>
        <obsoleted-by>
            <doc-id>RFC6724</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3484</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>SigComp</kw>
            <kw>Static Dictionary for Signaling Compression</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sipping-sigcomp-sip-dictionary-05</draft>
        <updated-by>
            <doc-id>RFC4896</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3485</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-compression-02</draft>
        <updated-by>
            <doc-id>RFC5049</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3486</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>circuit switched network resources</kw>
            <kw>end system resources</kw>
            <kw>proxy resources</kw>
            <kw>emergency preparedness communications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ieprep-sip-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <doi>10.17487/RFC3487</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>switches packet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-wu-rgmp-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3488</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>STUN</kw>
            <kw>Simple Traversal of User Datagram Protocol</kw>
            <kw>UDP</kw>
            <kw>NATs</kw>
            <kw>Network Address Translators</kw>
            <kw>lightweight</kw>
            <kw>applications</kw>
            <kw>firewalls</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-midcom-stun-05</draft>
        <obsoleted-by>
            <doc-id>RFC5389</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <doi>10.17487/RFC3489</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IDNs</kw>
            <kw>Internationalized Domain Names</kw>
            <kw>ascii</kw>
            <kw>characters</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idn-idna-14</draft>
        <obsoleted-by>
            <doc-id>RFC5890</doc-id>
            <doc-id>RFC5891</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>idn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3490</errata-url>
        <doi>10.17487/RFC3490</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IDN</kw>
            <kw>Internationalized Domain Name</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idn-nameprep-11</draft>
        <obsoleted-by>
            <doc-id>RFC5891</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>idn</wg_acronym>
        <doi>10.17487/RFC3491</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>IDNA</kw>
            <kw>Internationalized Domain Names in Applications</kw>
            <kw>syntax</kw>
            <kw>string host label</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-idn-punycode-03</draft>
        <updated-by>
            <doc-id>RFC5891</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>idn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3492</errata-url>
        <doi>10.17487/RFC3492</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <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><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC2553</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3493</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <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><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3494</errata-url>
        <doi>10.17487/RFC3494</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>packetcable</kw>
            <kw>MTA</kw>
            <kw>Media Terminal Adapter</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-packetcable-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3495</errata-url>
        <doi>10.17487/RFC3495</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>diff-serv</kw>
            <kw>diffserv</kw>
            <kw>rsvp-te</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-malis-diff-te-serviceclass-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3496</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real-time transport protocol</kw>
            <kw>hdtv</kw>
            <kw>high definition television</kw>
            <kw>SMPTE</kw>
            <kw>Society of Motion Picture and Television Engineers</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-smpte292-video-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3497</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>tcp/ip</kw>
            <kw>transmission control protocol</kw>
            <kw>internet protocol</kw>
            <kw>Synchronous Optical Network</kw>
            <kw>SONET</kw>
            <kw>Automatic Protection Switching</kw>
            <kw>APS</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-atommib-sonetaps-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC3498</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3499</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>108</page-count>
        <keywords>
            <kw>IMAPv4</kw>
            <kw>Internet Message Access Protocol</kw>
            <kw>Version 4rev1</kw>
            <kw>imapv4rev1</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-crispin-imapv-20</draft>
        <obsoletes>
            <doc-id>RFC2060</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9051</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4466</doc-id>
            <doc-id>RFC4469</doc-id>
            <doc-id>RFC4551</doc-id>
            <doc-id>RFC5032</doc-id>
            <doc-id>RFC5182</doc-id>
            <doc-id>RFC5738</doc-id>
            <doc-id>RFC6186</doc-id>
            <doc-id>RFC6858</doc-id>
            <doc-id>RFC7817</doc-id>
            <doc-id>RFC8314</doc-id>
            <doc-id>RFC8437</doc-id>
            <doc-id>RFC8474</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3501</errata-url>
        <doi>10.17487/RFC3501</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IMAPv4</kw>
            <kw>imap</kw>
            <kw>imapv4rev1</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-crispin-imap-multiappend-07</draft>
        <updated-by>
            <doc-id>RFC4466</doc-id>
            <doc-id>RFC4469</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3502</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MUA</kw>
            <kw>mail user agent</kw>
            <kw>imap4</kw>
            <kw>Internet Message Access Protocol</kw>
            <kw>MDN</kw>
            <kw>Message Disposition Notification</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-melnikov-imap-mdn-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3503</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-trade-iotp-v1-errata-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3504</errata-url>
        <doi>10.17487/RFC3504</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-trade-ecml2-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC3505</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>generic voucher language</kw>
            <kw>gvl</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-trade-drt-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC3506</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>http</kw>
            <kw>hyper-text markup protocol</kw>
            <kw>request</kw>
            <kw>response</kw>
            <kw>client server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-elson-icap-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3507</errata-url>
        <doi>10.17487/RFC3507</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>itu-t</kw>
            <kw>packet networks</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-levin-iptel-h323-url-scheme-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3508</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>traffic</kw>
            <kw>backbone</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ospf-abr-alt-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC3509</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>Internet Printing Protocol</kw>
            <kw>application</kw>
            <kw>media type</kw>
            <kw>URL</kw>
            <kw>Uniform Resource Locator</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC3510</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>client server</kw>
            <kw>traffic</kw>
            <kw>authentication</kw>
            <kw>web caching</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-firewall-08</draft>
        <obsoleted-by>
            <doc-id>RFC9411</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC3511</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>internet standard framework</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-snmpconf-bcp-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpconf</wg_acronym>
        <doi>10.17487/RFC3512</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>unicast</kw>
            <kw>anycast</kw>
            <kw>multicast</kw>
            <kw>node</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipngwg-addr-arch-v3-11</draft>
        <obsoletes>
            <doc-id>RFC2373</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4291</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3513</doi>
    </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>1</day>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>evil</kw>
            <kw>evil bit</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3514</errata-url>
        <doi>10.17487/RFC3514</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>resource request</kw>
            <kw>call transfer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-refer-07</draft>
        <updated-by>
            <doc-id>RFC7647</doc-id>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3515</errata-url>
        <doi>10.17487/RFC3515</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet message acess procotol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-nerenberg-imap-binary-07</draft>
        <updated-by>
            <doc-id>RFC4466</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3516</errata-url>
        <doi>10.17487/RFC3516</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>retransmission</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-allman-tcp-sack-13</draft>
        <obsoleted-by>
            <doc-id>RFC6675</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3517</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>PPP-BCP</kw>
            <kw>point-to-point protocol</kw>
            <kw>Bridging Control Protocol</kw>
            <kw>datagrams</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3518</doi>
    </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>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-mobileip-nat-traversal-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3519</errata-url>
        <doi>10.17487/RFC3519</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>session authorization policy</kw>
            <kw>admission control</kw>
            <kw>resource reservation</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rap-rsvp-authsession-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3520</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-rap-session-auth-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3521</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>loss recovery</kw>
            <kw>timestamps</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tsvwg-tcp-eifel-alg-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3522</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>naming convetions</kw>
            <kw>phone</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-polk-ieprep-scenarios-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <doi>10.17487/RFC3523</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>session description protocol</kw>
            <kw>SRF</kw>
            <kw>single reservation flow</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mmusic-reservation-flows-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC3524</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3525</doc-id>
        <title>Gateway Control Protocol Version 1</title>
        <author>
            <name>C. Groves</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Pantaleo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Anderson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>213</page-count>
        <keywords>
            <kw>MEGACO</kw>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-megaco-3015corr-02</draft>
        <obsoletes>
            <doc-id>RFC3015</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5125</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>megaco</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3525</errata-url>
        <doi>10.17487/RFC3525</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MODP</kw>
            <kw>More Modular Exponential</kw>
            <kw>IKE</kw>
            <kw>Internet Key Exchange</kw>
            <kw>bit groups</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-ike-modp-groups-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3526</errata-url>
        <doi>10.17487/RFC3526</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DHCPv4</kw>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-agent-subnet-selection-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3527</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>DA</kw>
            <kw>directory agent</kw>
            <kw>slpda</kw>
            <kw>service agent</kw>
            <kw>SA</kw>
            <kw>slpv2</kw>
            <kw>Mesh-enhanced Service Location Protocol</kw>
            <kw>mSLP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zhao-slp-da-interaction-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3528</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>XML-RPC</kw>
            <kw>Extensible Markup Language-Remote Procedure Calling</kw>
            <kw>format</kw>
            <kw>messages</kw>
            <kw>clients</kw>
            <kw>servers</kw>
            <kw>BEEP</kw>
            <kw>Blocks Extensible Exchange Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-harold-beep-xmlrpc-03</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3529</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>275</page-count>
        <keywords>
            <kw>NFSv4</kw>
            <kw>network file system</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-nfsv4-rfc3010bis-04</draft>
        <obsoletes>
            <doc-id>RFC3010</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7530</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3530</errata-url>
        <doi>10.17487/RFC3530</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>address plan</kw>
            <kw>addressing</kw>
            <kw>range</kw>
            <kw>space</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipv6-ipaddressassign-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3531</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>atm</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-gsmp-dyn-part-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>gsmp</wg_acronym>
        <doi>10.17487/RFC3532</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-pfeiffer-ogg-fileformat-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3533</errata-url>
        <doi>10.17487/RFC3533</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose internet mail extenstions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-walleij-ogg-mediatype-08</draft>
        <obsoleted-by>
            <doc-id>RFC5334</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3534</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Internet Architecture Board</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-nm-workshop-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3535</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>internet engineering task force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hoffman-i18n-terms-11</draft>
        <obsoleted-by>
            <doc-id>RFC6365</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3536</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>HMAC</kw>
            <kw>Hashed Message Authentication Code</kw>
            <kw>DES</kw>
            <kw>Data Encryption Standard</kw>
            <kw>AES</kw>
            <kw>Advanced Encryption Standard</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-hmac-key-wrap-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3537</errata-url>
        <doi>10.17487/RFC3537</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>payment</kw>
            <kw>input</kw>
            <kw>output</kw>
            <kw>parameter</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-trade-iotp-v1.0-set-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC3538</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>Authentication</kw>
            <kw>Authorization</kw>
            <kw>Accounting</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-aaa-transport-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <doi>10.17487/RFC3539</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ECN</kw>
            <kw>explicit congestion notification</kw>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tsvwg-tcp-nonce-04</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3540</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-walsh-urn-web3d-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3541</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipngwg-rfc2292bis-09</draft>
        <obsoletes>
            <doc-id>RFC2292</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3542</errata-url>
        <doi>10.17487/RFC3542</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>internet protocol</kw>
            <kw>mobile</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mobileip-reg-revok-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC3543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3544</doc-id>
        <title>IP Header Compression over PPP</title>
        <author>
            <name>T. Koren</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IPCOM-PPP</kw>
            <kw>internet protocol</kw>
            <kw>header compression</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3544</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Compressed Real-time Transport Protocol</kw>
            <kw>CRTP</kw>
            <kw>PPP</kw>
            <kw>point to point</kw>
            <kw>header</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-crtp-enhance-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3545</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>transport layer security</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tls-extensions-06</draft>
        <obsoleted-by>
            <doc-id>RFC4366</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC3546</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>ISAMKP</kw>
            <kw>Internet Security Association and Key Management Protocol</kw>
            <kw>DOI</kw>
            <kw>Domain of Interpretation</kw>
            <kw>key management</kw>
            <kw>security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-msec-gdoi-07</draft>
        <obsoleted-by>
            <doc-id>RFC6407</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC3547</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>schemes</kw>
            <kw>data</kw>
            <kw>line-feeds</kw>
            <kw>alphabets</kw>
            <kw>base encoding</kw>
            <kw>hex</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-josefsson-base-encoding-04</draft>
        <obsoleted-by>
            <doc-id>RFC4648</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3548</errata-url>
        <doi>10.17487/RFC3548</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>internet protocol messaging system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-forces-netlink-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3549</errata-url>
        <doi>10.17487/RFC3549</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>104</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-Time Transport Protocol</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>RTCP</kw>
            <kw>RTP Control Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-new-12</draft>
        <obsoletes>
            <doc-id>RFC1889</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5506</doc-id>
            <doc-id>RFC5761</doc-id>
            <doc-id>RFC6051</doc-id>
            <doc-id>RFC6222</doc-id>
            <doc-id>RFC7022</doc-id>
            <doc-id>RFC7160</doc-id>
            <doc-id>RFC7164</doc-id>
            <doc-id>RFC8083</doc-id>
            <doc-id>RFC8108</doc-id>
            <doc-id>RFC8860</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0064</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3550</errata-url>
        <doi>10.17487/RFC3550</doi>
    </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>
            <file-format>PS</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>RTP-AV</kw>
            <kw>Real-time Transport Protocol</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>conference</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-profile-new-13</draft>
        <obsoletes>
            <doc-id>RFC1890</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5761</doc-id>
            <doc-id>RFC7007</doc-id>
            <doc-id>RFC8860</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0065</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3551</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>RFC</kw>
            <kw>Request for Comment </kw>
            <kw>Security Considerations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-sec-cons-03</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9416</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0072</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3552</errata-url>
        <doi>10.17487/RFC3552</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>uniform resource names</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3553</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>internet key exchange</kw>
            <kw>security</kw>
            <kw>SCTP</kw>
            <kw>Stream Control Transmission Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-sctp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC3554</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real time transport protocol</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-mime-06</draft>
        <obsoleted-by>
            <doc-id>RFC4855</doc-id>
            <doc-id>RFC4856</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3625</doc-id>
            <doc-id>RFC4629</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3555</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real time transport protocol</kw>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>RTCP</kw>
            <kw>RTP Control Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtcp-bw-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3556</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real time transport protocol</kw>
            <kw>DSR</kw>
            <kw>distributed speech recognition</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-dsr-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3557</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real time transport protocol</kw>
            <kw>bundled</kw>
            <kw>interleaved</kw>
            <kw>EVRC</kw>
            <kw>Enhanced Variable Rate Codecs</kw>
            <kw>SMV</kw>
            <kw>Selectable Mode Vocoders</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-evrc-smv-03</draft>
        <updated-by>
            <doc-id>RFC4788</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3558</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>maas</kw>
            <kw>multicast address allocation servers</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-malloc-malloc-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>malloc</wg_acronym>
        <doi>10.17487/RFC3559</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>Cryptographic Message Syntax</kw>
            <kw>security encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-cms-rsaes-oaep-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3560</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>AODV</kw>
            <kw>Ad hoc On-Demand Distance Vector</kw>
            <kw>unicast</kw>
            <kw>multiple nodes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-manet-aodv-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3561</errata-url>
        <doi>10.17487/RFC3561</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>bgp</kw>
            <kw>border gateway protocol</kw>
            <kw>security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-idr-md5-keys-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC3562</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-zinin-ietf-jtc1-aggr-01</draft>
        <updated-by>
            <doc-id>RFC6233</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3563</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>multi-protocol label switching</kw>
            <kw>bandwidth constraints model</kw>
            <kw>overbooking</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tewg-diff-te-reqts-07</draft>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC3564</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>AES</kw>
            <kw>Advanced Encryption Standard</kw>
            <kw>CMS</kw>
            <kw>Cryptographic Message Syntax</kw>
            <kw>security</kw>
            <kw>data encoding</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-aes-alg-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3565</errata-url>
        <doi>10.17487/RFC3565</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>Internet Protocol Security</kw>
            <kw>authentication</kw>
            <kw>hash security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-ciph-aes-xcbc-mac-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC3566</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>iso</kw>
            <kw>international standards organization</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-hmac-04</draft>
        <obsoleted-by>
            <doc-id>RFC5304</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3567</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>metrics</kw>
            <kw>routing</kw>
            <kw>redirection</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-cdi-known-request-routing-03</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>cdi</wg_acronym>
        <doi>10.17487/RFC3568</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>routing applications</kw>
            <kw>deployment interoperability</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ssm-overview-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ssm</wg_acronym>
        <doi>10.17487/RFC3569</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>production networks</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-cdi-scenarios-01</draft>
        <obsoleted-by>
            <doc-id>RFC6770</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>cdi</wg_acronym>
        <doi>10.17487/RFC3570</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>pib</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rap-feedback-fr-pib-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC3571</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>synchronous optical network</kw>
            <kw>synchronous digital hierarchy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ogura-ipv6-mapos-02</draft>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3572</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>pstn</kw>
            <kw>public switched telephone network. L2TP</kw>
            <kw>Layer 2 Tunneling Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-l2tpext-v92-moh-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3573</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>third generation parnership project</kw>
            <kw>packet</kw>
            <kw>ipv6</kw>
            <kw>ipv4</kw>
            <kw>internet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-3gpp-cases-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3574</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>Internet Assigned Numbers Authority</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access Server</kw>
            <kw>RADIUS</kw>
            <kw>Remote Authentication Dial In User Service</kw>
        </keywords>
        <abstract><p>This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-aboba-radius-iana-07</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
            <doc-id>RFC2868</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6929</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3575</errata-url>
        <doi>10.17487/RFC3575</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>nas</kw>
            <kw>network access server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-chiba-radius-dynamic-authorization-20</draft>
        <obsoleted-by>
            <doc-id>RFC5176</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3576</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmonmib-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3577</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>pstn</kw>
            <kw>public switched telephone network</kw>
            <kw>ISDN</kw>
            <kw>Integrated Services Digital Network</kw>
            <kw>ISUP</kw>
            <kw>User Part</kw>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sipping-overlap-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3578</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-aboba-radius-rfc2869bis-22</draft>
        <updates>
            <doc-id>RFC2869</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5080</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3579</errata-url>
        <doi>10.17487/RFC3579</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>authentication</kw>
            <kw>authorization and accounting</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-congdon-radius-8021x-29</draft>
        <updated-by>
            <doc-id>RFC7268</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3580</errata-url>
        <doi>10.17487/RFC3580</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>Symmetric Response Routing</kw>
            <kw>report client server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-symmetric-response-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3581</errata-url>
        <doi>10.17487/RFC3581</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>multi6</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-multi6-multihoming-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>multi6</wg_acronym>
        <doi>10.17487/RFC3582</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>routing packets</kw>
            <kw>node</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nsis-qos-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC3583</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network management protocol</kw>
            <kw>mib information base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpv3</wg_acronym>
        <doi>10.17487/RFC3584</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>Internet Protocol Security</kw>
            <kw>ike</kw>
            <kw>internet key exchange protocol</kw>
            <kw>core</kw>
            <kw>Constrained RESTful Environments</kw>
            <kw>pcim</kw>
            <kw>Policy Core Information Model</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsp-config-policy-model-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsp</wg_acronym>
        <doi>10.17487/RFC3585</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPSP</kw>
            <kw>Internet Protocol Security Policy</kw>
            <kw>data integrity</kw>
            <kw>authentication</kw>
            <kw>host network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsp-requirements-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsp</wg_acronym>
        <doi>10.17487/RFC3586</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>architecture</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3587</errata-url>
        <doi>10.17487/RFC3587</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>147</page-count>
        <keywords>
            <kw>aaa</kw>
            <kw>authentication authorization accounting</kw>
            <kw>ip mobility</kw>
            <kw>Diameter Base Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-aaa-diameter-17</draft>
        <obsoleted-by>
            <doc-id>RFC6733</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5729</doc-id>
            <doc-id>RFC5719</doc-id>
            <doc-id>RFC6408</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3588</errata-url>
        <doi>10.17487/RFC3588</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>iana</kw>
            <kw>allocation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-loughney-aaa-cc-3gpp-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3589</errata-url>
        <doi>10.17487/RFC3589</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MLD-IPv6</kw>
            <kw>Multicast Listener Discovery</kw>
            <kw>internet protocol</kw>
            <kw>router</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <doi>10.17487/RFC3590</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>174</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</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 transmission session</kw>
            <kw>optical multiplex section</kw>
            <kw>optical channel</kw>
            <kw>otuk</kw>
            <kw>odukt</kw>
            <kw>oduk</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-atommib-opticalmib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3591</errata-url>
        <doi>10.17487/RFC3591</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>SNMP</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>Synchronous Optical Network</kw>
            <kw>Synchronous Digital Hierarchy</kw>
            <kw>SONET</kw>
            <kw>SDH</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3592</errata-url>
        <doi>10.17487/RFC3592</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC3593</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>CCC</kw>
            <kw>CableLabs Client Configuration</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-pktc-kerb-tckt-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3594</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ops-ipv6-flowlabel-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC3595</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>domain name system</kw>
            <kw>DNS</kw>
            <kw>zone</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dnsext-rfc1886bis-03</draft>
        <obsoletes>
            <doc-id>RFC3152</doc-id>
            <doc-id>RFC1886</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0088</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3596</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>name server software</kw>
            <kw>compression</kw>
            <kw>transparency</kw>
            <kw>RR</kw>
            <kw>Resource Record</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
            <doc-id>RFC5395</doc-id>
            <doc-id>RFC6195</doc-id>
            <doc-id>RFC6895</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3597</errata-url>
        <doi>10.17487/RFC3597</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-murchison-sieve-subaddress-06</draft>
        <obsoleted-by>
            <doc-id>RFC5233</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3598</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3599</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC3300</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3700</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3600</errata-url>
        <doi>10.17487/RFC3600</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-allocchio-gstn-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3601</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>Internet Protocol Security</kw>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>payload</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <draft>draft-ietf-ipsec-ciph-aes-cbc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC3602</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>network access coordination</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-dcsgroup-sipping-proxy-proxy-03</draft>
        <obsoleted-by>
            <doc-id>RFC5503</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3603</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>controllers</kw>
            <kw>routers</kw>
            <kw>formats</kw>
            <kw>codes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-gsmp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>gsmp</wg_acronym>
        <doi>10.17487/RFC3604</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RTCP</kw>
            <kw>Real Time Control Protocol</kw>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>nat</kw>
            <kw>network access translation</kw>
            <kw>port mapping</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-mmusic-sdp4nat-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3605</errata-url>
        <doi>10.17487/RFC3605</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>ATM</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <draft>draft-ietf-atommib-atm2-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC3606</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-leech-chinese-lottery-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3607</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>user agent</kw>
            <kw>domain</kw>
            <kw>register</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-sip-scvrtdisco-04</draft>
        <updated-by>
            <doc-id>RFC5630</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3608</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>traceroute</kw>
            <kw>application</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ccamp-tracereq-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC3609</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>ciphers</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <draft>draft-housley-ccm-mode-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3610</errata-url>
        <doi>10.17487/RFC3610</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real time transport protocol</kw>
            <kw>packet</kw>
            <kw>type</kw>
            <kw>SDP</kw>
            <kw>session description protocol</kw>
            <kw>blocks</kw>
            <kw>XR</kw>
            <kw>Extended Report</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-avt-rtcp-report-extns-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3611</errata-url>
        <doi>10.17487/RFC3611</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <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><p>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".</p></abstract>
        <draft>draft-ietf-mpls-ldp-restart-applic-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3612</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet2</kw>
            <kw>middleware</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-hazelton-mace-urn-namespace-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3613</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-smith-urn-mpeg-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3614</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>messaging service</kw>
            <kw>interface software</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.</p></abstract>
        <draft>draft-gustin-goyens-urn-id-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3615</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>URN NID</kw>
            <kw>Uniform Resource Name Namespace Identification</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bellifemine-urn-fipa-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3616</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-lear-tftp-uri-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3617</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MSDP</kw>
            <kw>Multicast Source Discovery Protocol</kw>
            <kw>ipv4</kw>
            <kw>pim-sm</kw>
            <kw>independent multicast</kw>
            <kw>sparse-mode</kw>
            <kw>rp</kw>
            <kw>rendezvous point</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-msdp-spec-20</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>msdp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3618</errata-url>
        <doi>10.17487/RFC3618</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ethernet rings</kw>
            <kw>robust</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <draft>draft-shah-extreme-eaps-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3619</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>TUNNEL</kw>
            <kw>beep</kw>
            <kw>blocks extensible exchange protocol</kw>
            <kw>firewall</kw>
            <kw>application layer</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-idwg-beep-tunnel-05</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>idwg</wg_acronym>
        <doi>10.17487/RFC3620</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>data terminal equipment</kw>
            <kw>dte</kw>
            <kw>power sourcing equipment</kw>
            <kw>pse</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <draft>draft-ietf-hubmib-power-ethernet-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC3621</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>federated network identity</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.</p></abstract>
        <draft>draft-mealling-liberty-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3622</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>open shortest path first</kw>
            <kw>non-stop forwarding</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ospf-hitless-restart-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC3623</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>call agent</kw>
            <kw>endpoints</kw>
            <kw>naming conventions</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-foster-mgcp-bulkaudits-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3624</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-gellens-qcp-01</draft>
        <updates>
            <doc-id>RFC3555</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3625</errata-url>
        <doi>10.17487/RFC3625</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>OLSR</kw>
            <kw>Optimized Link State Routing</kw>
            <kw>mobile ad hoc</kw>
            <kw>wireless multipoint relays</kw>
            <kw>mpr</kw>
            <kw>mprs</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-manet-olsr-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3626</errata-url>
        <doi>10.17487/RFC3626</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>address space</kw>
            <kw>anycast</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-savola-ipv6-127-prefixlen-04</draft>
        <obsoleted-by>
            <doc-id>RFC6547</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3627</errata-url>
        <doi>10.17487/RFC3627</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>tokens</kw>
            <kw>public key certificates</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pkix-pr-tsa-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC3628</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>UTF-8</kw>
            <kw>UCS</kw>
            <kw>Universal Character Set</kw>
            <kw>Transformation</kw>
            <kw>Format</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-yergeau-rfc2279bis-05</draft>
        <obsoletes>
            <doc-id>RFC2279</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0063</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3629</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>open-shortest path first</kw>
            <kw>ink</kw>
            <kw>state</kw>
            <kw>advertisement</kw>
        </keywords>
        <abstract><p>This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.</p></abstract>
        <draft>draft-katz-yeung-ospf-traffic-10</draft>
        <updates>
            <doc-id>RFC2370</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4203</doc-id>
            <doc-id>RFC5786</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC3630</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>protocol</kw>
            <kw>host compromise</kw>
            <kw>dos</kw>
            <kw>denial of service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-secmech-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3631</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-hollenbeck-rfc2832bis-02</draft>
        <updates>
            <doc-id>RFC2832</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Legacy</stream>
        <doi>10.17487/RFC3632</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>automated delegation router</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6603</doc-id>
            <doc-id>RFC7550</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3633</errata-url>
        <doi>10.17487/RFC3633</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>KDC</kw>
            <kw>Key Distribution Center</kw>
            <kw>CCC</kw>
            <kw>CableLabs Client Configuration</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dhc-suboptions-kdc-serveraddress-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3634</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC3635</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>MAU-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-hubmib-mau-mib-v3-04</draft>
        <obsoletes>
            <doc-id>RFC2668</doc-id>
            <doc-id>RFC1515</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4836</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC3636</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-hubmib-wis-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC3637</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ETHER-MIB</kw>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>Ethernet</kw>
        </keywords>
        <abstract><p>This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC3638</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>port fields</kw>
            <kw>protocol number</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-service-id-considerations-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3639</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>real time transport protocol</kw>
            <kw>audio video streams</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-avt-mpeg4-simple-08</draft>
        <updated-by>
            <doc-id>RFC5691</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3640</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>asn.1</kw>
            <kw>abstract syntax notation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-legg-ldap-gser-04</draft>
        <updated-by>
            <doc-id>RFC4792</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3641</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>asn.1</kw>
            <kw>abstract syntax notation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-legg-ldap-gser-abnf-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3642</errata-url>
        <doi>10.17487/RFC3642</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>FC</kw>
            <kw>Fibre Channel</kw>
            <kw>ips</kw>
            <kw>ip storage</kw>
            <kw>frame header</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ips-fcencapsulation-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3643</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
            <kw>integrated differentiated</kw>
            <kw>object oriented</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-policy-qos-info-model-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>policy</wg_acronym>
        <doi>10.17487/RFC3644</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>GSS-TSIG</kw>
            <kw>Generic Security Service Algorithm</kw>
            <kw>Secret Key Transaction Authentication for DNS</kw>
            <kw>domain name system</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3645</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>service</kw>
            <kw>server</kw>
            <kw>client</kw>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-opt-dnsconfig-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3646</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>pkix</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3647</errata-url>
        <doi>10.17487/RFC3647</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>WebDAV</kw>
            <kw>Web Distribution Authoring and Versioning</kw>
            <kw>server client semantics</kw>
            <kw>ordering</kw>
            <kw>orderpatch method</kw>
            <kw>position header</kw>
            <kw>ordering-type header</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-webdav-ordering-protocol-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <doi>10.17487/RFC3648</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>round-trip</kw>
            <kw>rate packet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tsvwg-highspeed-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3649</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>name service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-sun-handle-system-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3650</errata-url>
        <doi>10.17487/RFC3650</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>name service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-sun-handle-system-def-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3651</errata-url>
        <doi>10.17487/RFC3651</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>name service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-sun-handle-system-protocol-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3652</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>digital signature</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-xmldsig-xpf2-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>xmldsig</wg_acronym>
        <doi>10.17487/RFC3653</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>forces</kw>
            <kw>forwarding control</kw>
            <kw>element separation data</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-forces-requirements-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC3654</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3655</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Mailbox Update</kw>
            <kw>MUPDATE</kw>
            <kw>Distributed Mailbox Database Protocol</kw>
            <kw>imap</kw>
            <kw>pop3</kw>
            <kw>post office protocol</kw>
            <kw>internet message access protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-siemborski-mupdate-04</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3656</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>Cryptographic Message Syntax</kw>
            <kw>security</kw>
            <kw>mail content</kw>
            <kw>key</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).</p></abstract>
        <draft>draft-ietf-smime-camellia-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3657</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>zone cut</kw>
            <kw>zone key</kw>
            <kw>security</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3658</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3659</doc-id>
        <title>Extensions to FTP</title>
        <author>
            <name>P. Hethmon</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>file transfer protocol</kw>
            <kw>stream mode</kw>
            <kw>data transfer storage</kw>
        </keywords>
        <abstract><p>This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode.  It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ftpext-mlst-16</draft>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ftpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3659</errata-url>
        <doi>10.17487/RFC3659</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>generic</kw>
            <kw>line</kw>
            <kw>trunk</kw>
            <kw>handset</kw>
            <kw>dtmf</kw>
            <kw>dual tone multifrequency</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-foster-mgcp-basic-packages-10</draft>
        <updates>
            <doc-id>RFC2705</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3660</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>guidelines</kw>
            <kw>call agent</kw>
            <kw>implementation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-foster-mgcp-returncodes-03</draft>
        <updates>
            <doc-id>RFC3435</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3661</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>traffic network</kw>
            <kw>ds</kw>
            <kw>le</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bless-diffserv-pdb-le-01</draft>
        <obsoleted-by>
            <doc-id>RFC8622</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3662</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>referral types</kw>
            <kw>well-known</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-newton-ldap-whois-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3663</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>Internet Key Exchange Protocol</kw>
            <kw>ipsec</kw>
            <kw>IP Security</kw>
            <kw>AES</kw>
            <kw>advanced encryption standard</kw>
            <kw>mac</kw>
            <kw>message authentication code</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipsec-aes-xcbc-prf-01</draft>
        <obsoleted-by>
            <doc-id>RFC4434</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC3664</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>user agent</kw>
            <kw>client proxy</kw>
            <kw>redirect</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3665</errata-url>
        <doi>10.17487/RFC3665</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>118</page-count>
        <keywords>
            <kw>user proxy</kw>
            <kw>gateway</kw>
            <kw>telephony</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3666</errata-url>
        <doi>10.17487/RFC3666</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>intellectual property rights</kw>
            <kw>copyright</kw>
            <kw>ipr</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <doi>10.17487/RFC3667</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ipr</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <doi>10.17487/RFC3668</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ipr</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipr-wg-guidelines-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <doi>10.17487/RFC3669</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>97</page-count>
        <keywords>
            <kw>QoS</kw>
            <kw>quality of service</kw>
            <kw>host</kw>
            <kw>network devices</kw>
            <kw>traffic</kw>
        </keywords>
        <abstract><p>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</p></abstract>
        <draft>draft-ietf-policy-qos-device-info-model-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>policy</wg_acronym>
        <doi>10.17487/RFC3670</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>x.500</kw>
            <kw>information model schema</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zeilenga-ldap-collective-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3671</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>special subtree</kw>
        </keywords>
        <abstract><p>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).</p></abstract>
        <draft>draft-zeilenga-ldap-subentry-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3672</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>user mechanisms</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zeilenga-ldap-opattrs-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3673</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>elective extensions</kw>
            <kw>mechanisms</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zeilenga-ldap-features-05</draft>
        <obsoleted-by>
            <doc-id>RFC4512</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3674</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>top level domains</kw>
            <kw>tld</kw>
            <kw>ip addresses</kw>
            <kw>internet protocol filters</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-eastlake-xxx-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3675</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>media type</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3676</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IETF</kw>
            <kw>Internet Engineering Task Force</kw>
            <kw>ISOC</kw>
            <kw>Internet Society</kw>
            <kw>Board of Trustees</kw>
        </keywords>
        <abstract><p>This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.</p></abstract>
        <draft>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>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3677</errata-url>
        <doi>10.17487/RFC3677</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ip</kw>
            <kw>internet protocol</kw>
            <kw>application program interface</kw>
            <kw>apis</kw>
            <kw>input</kw>
            <kw>output</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-magma-msf-api-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3678</errata-url>
        <doi>10.17487/RFC3678</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-dhc-unused-optioncodes-07</draft>
        <updated-by>
            <doc-id>RFC8910</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3679</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>REGISTER</kw>
            <kw>event package name</kw>
            <kw>event package parameters</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sipping-reg-event-00</draft>
        <updated-by>
            <doc-id>RFC6140</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3680</errata-url>
        <doi>10.17487/RFC3680</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3681</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>time to live</kw>
            <kw>packet hop limit</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-gill-gtsh-04</draft>
        <obsoleted-by>
            <doc-id>RFC5082</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3682</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-mrose-ietf-posting-04</draft>
        <updated-by>
            <doc-id>RFC9245</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0083</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3683</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>TBRPF</kw>
            <kw>Topology Dissemination Based on Reverse-Path Forwarding</kw>
            <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><p>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.</p></abstract>
        <draft>draft-ietf-manet-tbrpf-11</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC3684</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>messages</kw>
            <kw>portable commands</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-daboo-sieve-spamtest-04</draft>
        <obsoleted-by>
            <doc-id>RFC5235</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3685</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>AES</kw>
            <kw>Advanced Encryption Standard</kw>
            <kw>IPsec Internet Protocol Security</kw>
            <kw>ESP</kw>
            <kw>Encapsulating Security Payload</kw>
            <kw>authentication vector</kw>
            <kw>cipher block</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipsec-ciph-aes-ctr-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC3686</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>syntax data schema</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-legg-ldapext-component-matching-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3687</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3688</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ieprep-ets-general-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <doi>10.17487/RFC3689</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ieprep-ets-telephony-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <doi>10.17487/RFC3690</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>Internet Message Access Protocol</kw>
            <kw>mailbox session client</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-melnikov-imap-unselect-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3691</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>Internet Assigned Numbers Authority</kw>
            <kw>values</kw>
            <kw>implementations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3692</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>security privacy</kw>
            <kw>lo</kw>
            <kw>location object</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-geopriv-reqs-04</draft>
        <updated-by>
            <doc-id>RFC6280</doc-id>
            <doc-id>RFC7459</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3693</errata-url>
        <doi>10.17487/RFC3693</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>privacy security</kw>
            <kw>data information</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-geopriv-threat-analysis-01</draft>
        <updated-by>
            <doc-id>RFC6280</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC3694</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>Forward Error Correction</kw>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
            <kw>compact</kw>
            <kw>schemes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-supp-compact-01</draft>
        <obsoleted-by>
            <doc-id>RFC5445</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3695</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>top-level domains</kw>
            <kw>tlds</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-klensin-name-filters-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3696</errata-url>
        <doi>10.17487/RFC3696</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Flow Label</kw>
            <kw>nodes</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipv6-flow-label-09</draft>
        <obsoleted-by>
            <doc-id>RFC6437</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3697</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>directory services</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-zeilenga-ldap-user-schema-mr-00</draft>
        <updates>
            <doc-id>RFC2798</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4517</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3698</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3699</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>Official Protocols</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <obsoletes>
            <doc-id>RFC3600</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5000</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3700</errata-url>
        <doi>10.17487/RFC3700</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>protocotype</kw>
            <kw>software</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-fink-6bone-phaseout-04</draft>
        <obsoletes>
            <doc-id>RFC2471</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3701</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-sipping-aaa-req-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3702</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>Policy Core</kw>
            <kw>mapping classes</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-policy-core-schema-16</draft>
        <updated-by>
            <doc-id>RFC4104</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>policy</wg_acronym>
        <doi>10.17487/RFC3703</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>Internet Protocol</kw>
            <kw>DOS</kw>
            <kw>Denial of Service</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-savola-bcp38-multihoming-update-03</draft>
        <updates>
            <doc-id>RFC2827</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8704</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0084</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3704</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>High Capacity Textual Conventions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-adslmib-hc-tc-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <doi>10.17487/RFC3705</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>security authentication</kw>
            <kw>dead peer detection</kw>
            <kw>dpd</kw>
            <kw>keepalive</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipsec-dpd-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3706</errata-url>
        <doi>10.17487/RFC3706</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>directory services domain</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-crisp-requirements-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <doi>10.17487/RFC3707</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DSACK</kw>
            <kw>Duplicate Selective Acknowledgement</kw>
            <kw>SCTP</kw>
            <kw>Stream Control Transmission Protocol</kw>
            <kw>TSN</kw>
            <kw>Transmission Sequence Number</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tsvwg-dsack-use-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3708</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>authentication</kw>
            <kw>security identification</kw>
            <kw>certificates</kw>
        </keywords>
        <abstract><p>This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-logotypes-13</draft>
        <obsoleted-by>
            <doc-id>RFC9399</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6170</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3709</errata-url>
        <doi>10.17487/RFC3709</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>internet engineering steering group</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iesg-charter-03</draft>
        <updated-by>
            <doc-id>RFC3932</doc-id>
            <doc-id>RFC5742</doc-id>
            <doc-id>RFC8717</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC3710</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>SRTP</kw>
            <kw>Secure Real-time Transport Protocol</kw>
            <kw>authentication</kw>
            <kw>traffic</kw>
            <kw>cryptographic</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-srtp-09</draft>
        <updated-by>
            <doc-id>RFC5506</doc-id>
            <doc-id>RFC6904</doc-id>
            <doc-id>RFC9335</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3711</errata-url>
        <doi>10.17487/RFC3711</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>object classes</kw>
            <kw>attributes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-fleming-ldap-printer-schema-02</draft>
        <obsoleted-by>
            <doc-id>RFC7612</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3712</errata-url>
        <doi>10.17487/RFC3712</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>security</kw>
            <kw>key</kw>
            <kw>cryptographic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-nakajima-camellia-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3713</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Kempf</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>end-to-end</kw>
            <kw>qos</kw>
            <kw>qualify of service</kw>
            <kw>voip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-congestion-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3714</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>virtual private networks</kw>
            <kw>vpns</kw>
            <kw>intranet</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipsec-nat-reqts-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3715</errata-url>
        <doi>10.17487/RFC3715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3716</doc-id>
        <title>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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-advcomm-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3716</errata-url>
        <doi>10.17487/RFC3716</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>transport infrastructure</kw>
            <kw>routers</kw>
            <kw>high-speed</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipo-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>ipo</wg_acronym>
        <doi>10.17487/RFC3717</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-rmcgowan-unicode-procs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3718</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>routeing</kw>
            <kw>interior gateway protocol</kw>
            <kw>igp</kw>
            <kw>conformance</kw>
            <kw>ip traffic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-iso-interoperable-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3719</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>257</page-count>
        <keywords>
            <kw>iSCSI</kw>
            <kw>Internet Small Computer Systems Interface</kw>
            <kw>transport protocol</kw>
            <kw>tcp</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ips-iscsi-20</draft>
        <obsoleted-by>
            <doc-id>RFC7143</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3980</doc-id>
            <doc-id>RFC4850</doc-id>
            <doc-id>RFC5048</doc-id>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3720</errata-url>
        <doi>10.17487/RFC3720</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-ips-iscsi-name-disc-10</draft>
        <updated-by>
            <doc-id>RFC7143</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3721</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>iSCSI</kw>
            <kw>Internet Small Computer Systems Interface</kw>
            <kw>transport</kw>
            <kw>unique</kw>
            <kw>global</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ips-iscsi-string-prep-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3722</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>threat models</kw>
            <kw>performance</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ips-security-19</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3723</doi>
    </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>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Austein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>architectural guideline</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-e2e-futures-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3724</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>3pcc</kw>
            <kw>Third Party Call Control</kw>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3725</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>rsvp</kw>
            <kw>resource reservation protocol</kw>
            <kw>middleboxes</kw>
            <kw>nsis</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nsis-req-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC3726</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-legg-ldap-cmr-module-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3727</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>VDSL</kw>
            <kw>Very High Speed Digital Subscriber Lines</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-adslmib-vdsl-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3728</errata-url>
        <doi>10.17487/RFC3728</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>application performance</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-apm-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3729</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>shared framework mapping</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-provreg-epp-09</draft>
        <obsoleted-by>
            <doc-id>RFC4930</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3730</errata-url>
        <doi>10.17487/RFC3730</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-provreg-epp-domain-07</draft>
        <obsoleted-by>
            <doc-id>RFC4931</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <doi>10.17487/RFC3731</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-provreg-epp-host-07</draft>
        <obsoleted-by>
            <doc-id>RFC4932</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <doi>10.17487/RFC3732</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-provreg-epp-contact-07</draft>
        <obsoleted-by>
            <doc-id>RFC4933</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3733</errata-url>
        <doi>10.17487/RFC3733</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>mapping</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>tls</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-provreg-epp-tcp-06</draft>
        <obsoleted-by>
            <doc-id>RFC4934</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <doi>10.17487/RFC3734</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-provreg-epp-ext-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>provreg</wg_acronym>
        <doi>10.17487/RFC3735</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-stateless-04</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3736</errata-url>
        <doi>10.17487/RFC3736</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>IANA</kw>
            <kw>Internet Assigned Numbers Authority</kw>
            <kw>RMON</kw>
            <kw>Registry of Remote Monitoring</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rmonmib-rmon-oid-assignments-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3737</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>WEBRC</kw>
            <kw>Wave and Equation Based Rate Control</kw>
            <kw>congestion control</kw>
            <kw>data delivery</kw>
            <kw>multicast</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-bb-webrc-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3738</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3739</errata-url>
        <doi>10.17487/RFC3739</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>data packets</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-msec-arch-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC3740</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>namespace</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-xmldsig-xc14n-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>xmldsig</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3741</errata-url>
        <doi>10.17487/RFC3741</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission control protocol</kw>
            <kw>congestion</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-tsvwg-slowstart-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3742</errata-url>
        <doi>10.17487/RFC3742</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-jseng-idn-admin-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3743</errata-url>
        <doi>10.17487/RFC3743</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>WebDAV</kw>
            <kw>Web Distributed Authoring and Versioning</kw>
            <kw>Access Control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-webdav-acl-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3744</errata-url>
        <doi>10.17487/RFC3744</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>JPEG</kw>
            <kw>joint photographic experts group</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-singer-jp2-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3745</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>network elements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-forces-framework-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3746</errata-url>
        <doi>10.17487/RFC3746</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>diffserv</kw>
            <kw>differentiated services</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-snmpconf-diffpolicy-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpconf</wg_acronym>
        <doi>10.17487/RFC3747</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>PPP-EAP</kw>
            <kw>Extensible Authentication Protocol</kw>
            <kw>data link layers</kw>
            <kw>point-to-point</kw>
            <kw>ieee 802</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-eap-rfc2284bis-09</draft>
        <obsoletes>
            <doc-id>RFC2284</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5247</doc-id>
            <doc-id>RFC7057</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>eap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3748</errata-url>
        <doi>10.17487/RFC3748</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>Transport Layer Security</kw>
            <kw>lossless data compression</kw>
            <kw>handshake protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tls-compression-07</draft>
        <updated-by>
            <doc-id>RFC8447</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC3749</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>single subnet</kw>
            <kw>gateway</kw>
            <kw>isp</kw>
            <kw>internet service provider</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-unman-scenarios-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3750</doi>
    </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>1</day>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-bradner-op-req-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3751</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>application data services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-opes-scenarios-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3752</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>networks</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-seamoby-mobility-terminology-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC3753</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-bless-diffserv-multicast-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3754</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3755</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>security key management</kw>
        </keywords>
        <abstract><p>The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH).  However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management.  This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery.  The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-send-psreq-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>send</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3756</errata-url>
        <doi>10.17487/RFC3756</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>dnssec</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3757</errata-url>
        <doi>10.17487/RFC3757</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>Stream Control Transmission Protocol</kw>
            <kw>init</kw>
            <kw>init ack</kw>
            <kw>forward tsn</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-prsctp-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3758</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <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><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3759</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-sacred-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacred</wg_acronym>
        <doi>10.17487/RFC3760</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>E.164</kw>
            <kw>URI</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>DDDS</kw>
            <kw>Dynamic Delegation Discovery System</kw>
            <kw>DNS</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-enum-rfc2916bis-07</draft>
        <obsoletes>
            <doc-id>RFC2916</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6116</doc-id>
            <doc-id>RFC6117</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC3761</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ENUM</kw>
            <kw>Telephone Number Mapping</kw>
            <kw>multimedia</kw>
            <kw>packet based network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-enum-h323-01</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC3762</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>performance metrics</kw>
            <kw>delay</kw>
            <kw>unidirectional</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ippm-owdp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC3763</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>aor</kw>
            <kw>Addresses-of-Record</kw>
            <kw>electronic number</kw>
            <kw>ENUM</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-enum-sip-01</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC3764</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>peer connections</kw>
            <kw>propagated</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ptomaine-nopeer-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3765</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>security</kw>
            <kw>cryptography algorithms</kw>
            <kw>integers</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3766</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>beep</kw>
            <kw>blocks extensible exchange protocol</kw>
            <kw>xml</kw>
            <kw>extensible mark up language</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sacred-protocol-bss-09</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacred</wg_acronym>
        <doi>10.17487/RFC3767</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>VRRP</kw>
            <kw>Virtual Router Redundancy Protocol</kw>
            <kw>lan</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-vrrp-spec-v2-10</draft>
        <obsoletes>
            <doc-id>RFC2338</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5798</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>vrrp</wg_acronym>
        <doi>10.17487/RFC3768</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipv6-prefix-delegation-requirement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3769</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ssid</kw>
            <kw>system service identifiers</kw>
            <kw>eap</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-wlan-extns-05</draft>
        <obsoleted-by>
            <doc-id>RFC4334</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3770</errata-url>
        <doi>10.17487/RFC3770</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>LDAPv3</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-rharrison-ldap-intermediate-resp-01</draft>
        <obsoleted-by>
            <doc-id>RFC4511</doc-id>
            <doc-id>RFC4510</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2251</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3771</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>Point-to-Point</kw>
            <kw>link control protocol</kw>
            <kw>lcp</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pppext-vendor-protocol-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3772</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ivm</kw>
            <kw>internet voice messaging</kw>
            <kw>voice profile for internet mail</kw>
            <kw>vpim</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-vpim-ivm-goals-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC3773</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>ietf</kw>
            <kw>process</kw>
            <kw>problem</kw>
            <kw>analysis</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-problem-issue-statement-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>problem</wg_acronym>
        <doi>10.17487/RFC3774</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>165</page-count>
        <keywords>
            <kw>mobility</kw>
            <kw>internet protocol</kw>
            <kw>nodes</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mobileip-ipv6-24</draft>
        <obsoleted-by>
            <doc-id>RFC6275</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC3775</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>security</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mobileip-mipv6-ha-ipsec-06</draft>
        <updated-by>
            <doc-id>RFC4877</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mobileip</wg_acronym>
        <doi>10.17487/RFC3776</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>IESG</kw>
            <kw>Internet Architecture Board</kw>
            <kw>Internet Engineering Steering Group</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-nomcom-rfc2727bis-09</draft>
        <obsoletes>
            <doc-id>RFC2727</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7437</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5078</doc-id>
            <doc-id>RFC5633</doc-id>
            <doc-id>RFC5680</doc-id>
            <doc-id>RFC6859</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>nomcom</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3777</errata-url>
        <doi>10.17487/RFC3777</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>portable document format</kw>
            <kw>document exchange</kw>
            <kw>digital signatures</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zilles-pdf-03</draft>
        <obsoleted-by>
            <doc-id>RFC8118</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3778</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>X.509</kw>
            <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><p>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]</p></abstract>
        <draft>draft-ietf-pkix-x509-ipaddr-as-extn-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3779</errata-url>
        <doi>10.17487/RFC3779</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>SMIng</kw>
            <kw>Structure of Management Information</kw>
            <kw>Next Generation</kw>
            <kw>data definition language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-nmrg-sming-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3780</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>data definition language</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-irtf-nmrg-sming-snmp-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3781</errata-url>
        <doi>10.17487/RFC3781</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>Transmission Control Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-newreno-02</draft>
        <obsoletes>
            <doc-id>RFC2582</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6582</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3782</errata-url>
        <doi>10.17487/RFC3782</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet Small Computer Systems Interface</kw>
            <kw>iscsi</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ips-command-ordering-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3783</errata-url>
        <doi>10.17487/RFC3783</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>link state protocol</kw>
            <kw>lsp</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-traffic-05</draft>
        <obsoleted-by>
            <doc-id>RFC5305</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4205</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3784</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>Interior Gateway Protocol</kw>
            <kw>MPLS</kw>
            <kw>MultiProtocol Label Switching</kw>
            <kw>TE</kw>
            <kw>Traffic Engineering</kw>
            <kw>link</kw>
            <kw>bandwidth router</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC3785</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-ext-lsp-frags-02</draft>
        <obsoleted-by>
            <doc-id>RFC5311</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3786</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>routing traffic</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-ip-interoperable-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3787</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SIGTRAN</kw>
            <kw>Signaling Transport</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sigtran-security-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3788</doi>
    </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, 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-intro-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3789</doi>
    </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, II</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-int-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3790</doi>
    </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, II</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-routing-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3791</doi>
    </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, 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-sec-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3792</doi>
    </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, 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-subip-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3793</doi>
    </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, 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-trans-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3794</doi>
    </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, II</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-apps-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3795</doi>
    </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, 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>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-ipv4survey-ops-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3796</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Internet Engineering Task Force</kw>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-eastlake-rfc2777bis-selection-04</draft>
        <obsoletes>
            <doc-id>RFC2777</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3797</errata-url>
        <doi>10.17487/RFC3797</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>EMF-MDN</kw>
            <kw>MDN</kw>
            <kw>Message Disposition Notifications</kw>
            <kw>media-type</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-vaudreuil-mdnbis-05</draft>
        <obsoletes>
            <doc-id>RFC2298</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8098</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3461</doc-id>
            <doc-id>RFC2046</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5337</doc-id>
            <doc-id>RFC6533</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3798</errata-url>
        <doi>10.17487/RFC3798</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3799</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3800</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>MIME-VP2</kw>
            <kw>vpim</kw>
            <kw>Voice Profile for Internet Mail</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC3801</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>MIME-ADPCM</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>Adaptive Differential Pulse Code Modulation</kw>
            <kw>audio</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC3802</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>CONT-DUR</kw>
            <kw>Content Duration</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>time</kw>
            <kw>media</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC3803</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>VPIM</kw>
            <kw>Voice Profile for Internet Mail</kw>
            <kw>formats</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-vpim-address-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC3804</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>171</page-count>
        <keywords>
            <kw>Print-MIB</kw>
            <kw>Printer</kw>
            <kw>Management Information Base</kw>
            <kw>snmp</kw>
            <kw>management</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3805</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>finisher</kw>
            <kw>snmp</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-printmib-finishing-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3806</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3807</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>IANACharset</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-mcdonald-iana-charset-mib-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3808</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>service engineering</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-l3vpn-generic-reqts-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC3809</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>Multicast Listener Discovery</kw>
            <kw>ssm</kw>
            <kw>source filtering</kw>
            <kw>igmp</kw>
            <kw>group management</kw>
            <kw>mld</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-vida-mld-v2-08</draft>
        <obsoleted-by>
            <doc-id>RFC9777</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2710</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4604</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3810</errata-url>
        <doi>10.17487/RFC3810</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Textual Conventions</kw>
            <kw>TCs</kw>
            <kw>Multiprotocol Label Switching</kw>
            <kw>MPLS</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-tc-mib-10</draft>
        <updated-by>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3811</errata-url>
        <doi>10.17487/RFC3811</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Multiprotocol Label Switching</kw>
            <kw>TE</kw>
            <kw>Traffic Engineering</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-te-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3812</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-lsr-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3813</errata-url>
        <doi>10.17487/RFC3813</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Multiprotocol Label Switching</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>FEC</kw>
            <kw>Forwarding Equivalence Class</kw>
            <kw>NHLFE</kw>
            <kw>Next Hop Label Forwarding Entry</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-ftn-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3814</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>106</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Multiprotocol Label Switching</kw>
            <kw>LDP</kw>
            <kw>Label Distribution Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-ldp-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3815</errata-url>
        <doi>10.17487/RFC3815</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>Robust Header Compression</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rohc-mib-rtp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3816</errata-url>
        <doi>10.17487/RFC3816</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>point-to-point</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-dasilva-l2tp-relaysvc-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC3817</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>PPP</kw>
            <kw>Point-to-Point Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC3818</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>digital communication equipment</kw>
            <kw>link-layer protocols</kw>
            <kw>packet-switched local networks</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pilc-link-design-15</draft>
        <updated-by>
            <doc-id>RFC9599</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0089</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pilc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3819</errata-url>
        <doi>10.17487/RFC3819</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>PKI</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>authentication</kw>
            <kw>security credentials</kw>
            <kw>restricted delegation</kw>
            <kw>single-signon</kw>
            <kw>delegation of rights</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-pkix-proxy-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3820</errata-url>
        <doi>10.17487/RFC3820</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>FCIP</kw>
            <kw>Fibre Channel Over TCI/IP</kw>
            <kw>storage area networks</kw>
            <kw>IP-based networks</kw>
            <kw>unified storage area network</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ips-fcovertcpip-12</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3821</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>FCIP</kw>
            <kw>Fibre Channel over TCP/IP</kw>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
            <kw>dynamic discovery</kw>
        </keywords>
        <abstract><p>This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-fcip-slp-09</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3822</errata-url>
        <doi>10.17487/RFC3822</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>sub-type application/sbml+xml</kw>
            <kw>systems biology community</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-sbml-media-type-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3823</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>telephone records</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-sipping-e164-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3824</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>dhcp</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>lci</kw>
            <kw>geographic location</kw>
            <kw>LCI</kw>
            <kw>Location Configuration Information</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-geopriv-dhcp-lci-option-03</draft>
        <obsoleted-by>
            <doc-id>RFC6225</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC3825</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-blumenthal-aes-usm-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3826</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-sarcar-snoop-new-types-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3827</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>UDP-Lite</kw>
            <kw>Lightweight User Datagram Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-udp-lite-02</draft>
        <updated-by>
            <doc-id>RFC6335</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC3828</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>bind operation</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-weltman-ldapv3-auth-response-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3829</errata-url>
        <doi>10.17487/RFC3829</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>MIKEY</kw>
            <kw>Multimedia Internet KEYing</kw>
            <kw>key management scheme</kw>
            <kw>real-time applications</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-msec-mikey-08</draft>
        <updated-by>
            <doc-id>RFC4738</doc-id>
            <doc-id>RFC6309</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3830</errata-url>
        <doi>10.17487/RFC3830</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>addresses</kw>
            <kw>link-local</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-imss-ipv6-over-fibre-channel-02</draft>
        <obsoleted-by>
            <doc-id>RFC4338</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC3831</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SLP</kw>
            <kw>Service Location Protocol</kw>
            <kw>DNS-SRV</kw>
            <kw>domain name system</kw>
            <kw>resource record</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-zhao-slp-remote-da-discovery-06</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3832</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>data disclosure</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-dnsext-dns-threats-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3833</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>automatic mail responders</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-moore-auto-email-response-05</draft>
        <updated-by>
            <doc-id>RFC5436</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3834</errata-url>
        <doi>10.17487/RFC3834</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>application service</kw>
            <kw>data stream service</kw>
            <kw>data consumer</kw>
            <kw>data dispatcher architecture</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-opes-architecture-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3835</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>callout protocol</kw>
            <kw>remote execution</kw>
            <kw>OPES services</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-opes-protocol-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3836</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>threat discovery</kw>
            <kw>threat analysis</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-opes-threats-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3837</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>opes flow</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-opes-authorization-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3838</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>standard MIME types</kw>
            <kw>3GPP multimedia file format</kw>
            <kw>ISO Media File Format</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-singer-avt-3gpp-mime-01</draft>
        <updated-by>
            <doc-id>RFC6381</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3839</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>User Agent</kw>
            <kw>ua</kw>
            <kw>contact header field</kw>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-callee-caps-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3840</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>Uniform Resource Identifiers</kw>
            <kw>URI</kw>
            <kw>Accept-Contact</kw>
            <kw>Reject-Contact</kw>
            <kw>Request-Disposition</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-callerprefs-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3841</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>message waiting status</kw>
            <kw>message summary</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sipping-mwi-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3842</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>RObust Header Compression</kw>
            <kw>compression protocols</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-rohc-ip-only-05</draft>
        <updated-by>
            <doc-id>RFC4815</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC3843</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3844</doc-id>
        <title>IETF Problem Resolution Process</title>
        <author>
            <name>E. Davies</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Hofmann</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ietf</kw>
            <kw>process</kw>
            <kw>problem</kw>
            <kw>analysis</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-problem-process-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>problem</wg_acronym>
        <doi>10.17487/RFC3844</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <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><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC3845</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>NAI</kw>
            <kw>Network Access Identifiers</kw>
            <kw>internet protocol</kw>
            <kw>home aaa server</kw>
            <kw>ha server</kw>
            <kw>home agents</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mip4-aaa-nai-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC3846</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>LSP database synchronization</kw>
            <kw>transient routing disruption</kw>
            <kw>database synchronization</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-isis-restart-05</draft>
        <obsoleted-by>
            <doc-id>RFC5306</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC3847</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>smtp</kw>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-newman-esmtpsa-01</draft>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3848</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>unicast</kw>
            <kw>site-local</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-huston-ipv6-documentation-prefix-03</draft>
        <updated-by>
            <doc-id>RFC9637</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3849</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>x.509</kw>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>mime</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>secure</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-rfc2632bis-07</draft>
        <obsoletes>
            <doc-id>RFC2632</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5750</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3850</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>secure</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-rfc2633bis-09</draft>
        <obsoletes>
            <doc-id>RFC2633</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5751</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3851</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>Cryptographic Message Syntax</kw>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <abstract><p>This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-rfc3369bis-04</draft>
        <obsoletes>
            <doc-id>RFC3369</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5652</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4853</doc-id>
            <doc-id>RFC5083</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3852</errata-url>
        <doi>10.17487/RFC3852</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>AES</kw>
            <kw>Advanced Encryption Standard</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3853</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>secure</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>encryption</kw>
            <kw>cryptographic signature</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-x400wrap-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC3854</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>cms</kw>
            <kw>cryptographic message syntax message</kw>
            <kw>MIME</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
            <kw>secure</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-smime-x400transport-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3855</errata-url>
        <doi>10.17487/RFC3855</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>subscription notification</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-simple-presence-10</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3856</errata-url>
        <doi>10.17487/RFC3856</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-simple-winfo-package-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC3857</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Extensible Markup Language</kw>
            <kw>xml</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-simple-winfo-format-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3858</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>CPP</kw>
            <kw>Common Profile for Presence</kw>
            <kw>data formats</kw>
            <kw>semantics</kw>
            <kw>instant messaging</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-impp-pres-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3859</errata-url>
        <doi>10.17487/RFC3859</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>CPIM</kw>
            <kw>Common Profile for Instant Messaging</kw>
            <kw>data formats</kw>
            <kw>semantics</kw>
            <kw>instant messaging</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-impp-im-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <doi>10.17487/RFC3860</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-impp-srv-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <doi>10.17487/RFC3861</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>instant messaging and common presence protocol</kw>
            <kw>message/cpim</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-impp-cpim-msgfmt-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3862</errata-url>
        <doi>10.17487/RFC3862</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-impp-cpim-pidf-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>impp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3863</errata-url>
        <doi>10.17487/RFC3863</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Internet mail</kw>
            <kw>HTTP</kw>
            <kw>Netnews</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-klyne-msghdr-registry-07</draft>
        <updated-by>
            <doc-id>RFC9110</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0090</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3864</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>Simple Mail Transfer Protocol</kw>
            <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><p>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]</p></abstract>
        <draft>draft-malamud-no-soliciting-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3865</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>lightweight directory access protocol</kw>
            <kw>servers</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3866</errata-url>
        <doi>10.17487/RFC3866</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>106</page-count>
        <keywords>
            <kw>modules</kw>
            <kw>data format exchange</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p><p> 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.</p></abstract>
        <draft>draft-ietf-trade-iotp-v1.0-papi-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC3867</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>131</page-count>
        <keywords>
            <kw>SUA</kw>
            <kw>Signaling Connection Control Part User Adaptation Layer</kw>
            <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><p>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]</p></abstract>
        <draft>draft-ietf-sigtran-sua-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3868</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>internet infrastructure</kw>
            <kw>non-commercial funding</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-research-funding-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3869</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-swartz-rdfcore-rdfxml-mediatype-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3870</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-jones-opsec-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3871</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>TRIP</kw>
            <kw>Telephony Routing over IP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-iptel-trip-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC3872</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>Stream Control Transmission Protocol</kw>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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.</p><p> 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]</p></abstract>
        <draft>draft-ietf-sigtran-sctp-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC3873</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>secure standard</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pkix-sha224-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC3874</doi>
    </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>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>www</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p></abstract>
        <draft>draft-coar-cgi-v11-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3875</errata-url>
        <doi>10.17487/RFC3875</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>attribute</kw>
            <kw>filter</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ldapext-matchedval-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3876</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>Management Information Base</kw>
            <kw>alarm mib</kw>
            <kw>iana-itu-alarm-tc-mib</kw>
            <kw>itu-alarm-tc-mib</kw>
            <kw>itu-alarm-mib</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-disman-alarm-mib-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3877</errata-url>
        <doi>10.17487/RFC3877</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>alarm condition</kw>
            <kw>probably cause</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-disman-conditionmib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC3878</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>ipv6</kw>
            <kw>architecture</kw>
            <kw>site-local</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipv6-deprecate-site-local-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC3879</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>CPL</kw>
            <kw>Call Processing Language</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-iptel-cpl-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC3880</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems.  The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers.  It consolidates several previous documents on security auditing of healthcare data.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-marshall-security-audit-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3881</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>dos</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-turk-bgp-dos-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3882</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>OSPF-DC</kw>
            <kw>Open Shortest Path First</kw>
            <kw>Demand Circuits</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC3883</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-touch-ipsec-vpn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3884</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>msgtrk</wg_acronym>
        <doi>10.17487/RFC3885</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Delivery Status Notifications</kw>
            <kw>DSN</kw>
            <kw>Message Disposition Notifications</kw>
            <kw>MDN</kw>
        </keywords>
        <abstract><p>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.</p><p> 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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>msgtrk</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3886</errata-url>
        <doi>10.17487/RFC3886</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Message Tracking Query Protocol</kw>
            <kw>MTQP</kw>
            <kw>ESMTP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-msgtrk-mtqp-12</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>msgtrk</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3887</errata-url>
        <doi>10.17487/RFC3887</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Message Tracking</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-msgtrk-model-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>msgtrk</wg_acronym>
        <doi>10.17487/RFC3888</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3889</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>Session Description Protocol</kw>
            <kw>TIAS</kw>
            <kw>Transport Independent Application Specific Maximum</kw>
        </keywords>
        <abstract><p>This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.</p><p> The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-bwparam-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC3890</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>multi-party applications</kw>
            <kw>call control</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-replaces-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3891</errata-url>
        <doi>10.17487/RFC3891</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>REFER</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-referredby-05</draft>
        <updated-by>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3892</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <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><p>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]</p></abstract>
        <draft>draft-ietf-sip-authid-body-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3893</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Sieve</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract><p>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.</p><p> 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]</p></abstract>
        <draft>draft-degener-sieve-copy-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3894</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-atommib-rfc2495bis-06</draft>
        <obsoletes>
            <doc-id>RFC2495</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4805</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC3895</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>DS3-E3-MIB</kw>
            <kw>management information base</kw>
            <kw>Interface Type</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>atommib</wg_acronym>
        <doi>10.17487/RFC3896</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>tracing</kw>
            <kw>non-blocking</kw>
            <kw>bypass</kw>
        </keywords>
        <abstract><p>This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-opes-end-comm-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3897</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Network Information Service</kw>
            <kw>NIS Servers</kw>
            <kw>NIS+ Servers</kw>
            <kw>NIS Client Domain Name</kw>
            <kw>NIS+ Client Domain name</kw>
            <kw>DHCPv6</kw>
            <kw>Dynamic Host Configuration Protocol for IPV6</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-opt-nisconfig-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3898</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3899</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3900</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>domain name system</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC3901</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-baker-soap-media-reg-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3902</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>presence</kw>
            <kw>information</kw>
            <kw>package</kw>
        </keywords>
        <abstract><p>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.</p><p> 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]</p></abstract>
        <draft>draft-ietf-sip-publish-04</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3903</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>home office</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-unmaneval-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC3904</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ipr</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipr-template-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3905</errata-url>
        <doi>10.17487/RFC3905</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>hop-by-hop link-state routing protocols</kw>
            <kw>SPF</kw>
            <kw>shortest path first</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rtgwg-igp-shortcut-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC3906</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3907</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3908</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>abandon operation</kw>
            <kw>outstanding operation</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-zeilenga-ldap-cancel-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3909</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>SPIRTS</kw>
            <kw>pstn</kw>
            <kw>Public Switched Telephone Network</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><p>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]</p></abstract>
        <draft>draft-ietf-spirits-protocol-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>spirits</wg_acronym>
        <doi>10.17487/RFC3910</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>Join header</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-join-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3911</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>WHOIS</kw>
            <kw>NICNAME</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3912</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>enter-domain</kw>
            <kw>source-specific multicast</kw>
            <kw>ssm</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bgmp-spec-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bgmp</wg_acronym>
        <doi>10.17487/RFC3913</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-opes-iab-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC3914</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
            <kw>EPP</kw>
            <kw>Extensible Provisioning Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-hollenbeck-epp-rgp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3915</errata-url>
        <doi>10.17487/RFC3915</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pwe3-requirements-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC3916</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>ipfix</kw>
            <kw>routers</kw>
            <kw>measurment</kw>
            <kw>middleboxes</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipfix-reqs-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC3917</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>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.</p><p> 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.</p></abstract>
        <draft>draft-ietf-bmwg-mcastm-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC3918</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mib</kw>
        </keywords>
        <abstract><p>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].</p><p> 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.</p></abstract>
        <draft>draft-ietf-rmonmib-pi-ipv6-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC3919</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>instant messaging</kw>
            <kw>im</kw>
            <kw>extensible markup language</kw>
            <kw>xml</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-xmpp-core-24</draft>
        <obsoleted-by>
            <doc-id>RFC6120</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6122</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3920</errata-url>
        <doi>10.17487/RFC3920</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>107</page-count>
        <keywords>
            <kw>instant messaging</kw>
            <kw>im</kw>
            <kw>extensible markup language</kw>
            <kw>xml</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-xmpp-im-22</draft>
        <obsoleted-by>
            <doc-id>RFC6121</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>xmpp</wg_acronym>
        <doi>10.17487/RFC3921</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>im</kw>
            <kw>instant messaging</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract><p>This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xmpp-cpim-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>xmpp</wg_acronym>
        <doi>10.17487/RFC3922</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>im</kw>
            <kw>instant messaging</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract><p>This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xmpp-e2e-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3923</errata-url>
        <doi>10.17487/RFC3923</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-baker-slem-architecture-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3924</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>dhc</kw>
            <kw>dhcp</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>class</kw>
            <kw>vendor-specific</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-vendor-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3925</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>FLUTE</kw>
            <kw>File Delivery over Unidirectional Transport</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-flute-08</draft>
        <obsoleted-by>
            <doc-id>RFC6726</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3926</errata-url>
        <doi>10.17487/RFC3926</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3927</doc-id>
        <title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Dynamic Configuration</kw>
            <kw>ip network</kw>
            <kw>ip address</kw>
            <kw>169.254/16</kw>
        </keywords>
        <abstract><p>To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.</p><p> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-zeroconf-ipv4-linklocal-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>zeroconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3927</errata-url>
        <doi>10.17487/RFC3927</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>LCUP</kw>
            <kw>Client Update Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ldup-lcup-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldup</wg_acronym>
        <doi>10.17487/RFC3928</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-hardie-alt-consensus-02</draft>
        <updated-by>
            <doc-id>RFC8717</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3929</errata-url>
        <doi>10.17487/RFC3929</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-eastlake-proto-doc-pov-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3930</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Layer Two Tunneling Protocol</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-l2tpext-l2tp-base-15</draft>
        <updated-by>
            <doc-id>RFC5641</doc-id>
            <doc-id>RFC9601</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3931</errata-url>
        <doi>10.17487/RFC3931</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IESG</kw>
            <kw>RFC Editor</kw>
            <kw>independent submission</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p></abstract>
        <draft>draft-iesg-rfced-documents-03</draft>
        <obsoleted-by>
            <doc-id>RFC5742</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2026</doc-id>
            <doc-id>RFC3710</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC3932</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Experiments</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3933</errata-url>
        <doi>10.17487/RFC3933</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BCP</kw>
            <kw>WG</kw>
            <kw>escape</kw>
            <kw>clause</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-wasserman-rfc2418-ml-update-01</draft>
        <updates>
            <doc-id>RFC2418</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0025</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3934</errata-url>
        <doi>10.17487/RFC3934</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Mission Statement</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3935</errata-url>
        <doi>10.17487/RFC3935</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource reservation protocol</kw>
            <kw>label</kw>
            <kw>switched</kw>
            <kw>paths</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3936</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-steidl-iptc-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3937</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>user agent</kw>
            <kw>ua</kw>
        </keywords>
        <abstract><p>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".</p><p> A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3938</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Voice Mail</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ema-vpim-clid-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3939</errata-url>
        <doi>10.17487/RFC3939</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>NACK</kw>
            <kw>Negative-acknowledgement</kw>
            <kw>Oriented Reliable Multicast</kw>
            <kw>NORM</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-pi-norm-10</draft>
        <obsoleted-by>
            <doc-id>RFC5740</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3940</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>NACK</kw>
            <kw>Negative-acknowledgement</kw>
            <kw>Oriented Reliable Multicast</kw>
            <kw>NORM</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-rmt-bb-norm-09</draft>
        <obsoleted-by>
            <doc-id>RFC5401</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC3941</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHCP-BOOTP</kw>
            <kw>Bootstrap</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3942</errata-url>
        <doi>10.17487/RFC3942</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>lossless data compression algorithm</kw>
            <kw>TLS Record Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-friend-tls-lzs-compression-04</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC3943</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <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><p>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.  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.</p></abstract>
        <draft>draft-johnson-h350-directory-serv-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3944</errata-url>
        <doi>10.17487/RFC3944</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>Generalized Multi-Protocol Label Switching</kw>
        </keywords>
        <abstract><p>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.</p><p> 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]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-architecture-07</draft>
        <updated-by>
            <doc-id>RFC6002</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3945</errata-url>
        <doi>10.17487/RFC3945</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-sonet-sdh-08</draft>
        <obsoleted-by>
            <doc-id>RFC4606</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC3946</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>Internet Key Exchange</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-nat-t-ike-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3947</errata-url>
        <doi>10.17487/RFC3947</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>ESP</kw>
            <kw>Encapsulating Security Payload</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipsec-udp-encaps-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3948</errata-url>
        <doi>10.17487/RFC3948</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <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><p>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.</p><p> 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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3949</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <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><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC3950</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>194</page-count>
        <keywords>
            <kw>iLBC</kw>
            <kw>Internet Low Bit Rate Codec</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-avt-ilbc-codec-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3951</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-time Transport Protocol</kw>
            <kw>iLBC</kw>
            <kw>internet Low Bit Rate Codec</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-avt-rtp-ilbc-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3952</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>uri</kw>
            <kw>provisioning pres</kw>
            <kw>ENUM</kw>
            <kw>Telephone Number Mapping</kw>
        </keywords>
        <abstract><p>This document registers a Telephone Number Mapping (ENUM) service for presence.  Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-pres-01</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC3953</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-claise-netflow-9-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3954</errata-url>
        <doi>10.17487/RFC3954</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-leinen-ipfix-eval-contrib-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC3955</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RP</kw>
            <kw>Rendezvous Point</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mboned-embeddedrp-07</draft>
        <updates>
            <doc-id>RFC3306</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7371</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC3956</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
        </keywords>
        <abstract><p>Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers.  Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent.  When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node.  This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-aaa-key-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC3957</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>DDDS</kw>
            <kw>Dynamic Delegation Discovery System</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-daigle-snaptr-01</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3958</errata-url>
        <doi>10.17487/RFC3958</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sipping-early-disposition-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3959</errata-url>
        <doi>10.17487/RFC3959</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-sipping-early-media-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC3960</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-krb-wg-crypto-07</draft>
        <updated-by>
            <doc-id>RFC8429</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3961</errata-url>
        <doi>10.17487/RFC3961</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>kerberos cryptosystem suite</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-raeburn-krb-rijndael-krb-07</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC3962</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>mobile ipv6</kw>
            <kw>session continuity</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-nemo-basic-support-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <doi>10.17487/RFC3963</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-6to4-security-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3964</errata-url>
        <doi>10.17487/RFC3964</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SMFAX-IM</kw>
            <kw>Simple Mode of Facsimile Using Internet Mail</kw>
            <kw>data</kw>
            <kw>file</kw>
            <kw>format</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract><p>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.</p><p> This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3965</errata-url>
        <doi>10.17487/RFC3965</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>URI</kw>
            <kw>uniform resource identifier</kw>
            <kw>locator</kw>
            <kw>schemes</kw>
            <kw>tel</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-iptel-rfc2806bis-09</draft>
        <obsoletes>
            <doc-id>RFC2806</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5341</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3966</errata-url>
        <doi>10.17487/RFC3966</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ymbk-downref-03</draft>
        <updated-by>
            <doc-id>RFC4897</doc-id>
            <doc-id>RFC8067</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0097</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3967</errata-url>
        <doi>10.17487/RFC3967</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3968</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-sip-uri-parameter-reg-02</draft>
        <updates>
            <doc-id>RFC3427</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5727</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0099</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC3969</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Management Information Base</kw>
            <kw>TE</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tewg-mib-08</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>Legacy</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc3970</errata-url>
        <doi>10.17487/RFC3970</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>Neighbor Discovery Protocol</kw>
            <kw>NDP</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-send-ndopt-06</draft>
        <updated-by>
            <doc-id>RFC6494</doc-id>
            <doc-id>RFC6495</doc-id>
            <doc-id>RFC6980</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>send</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3971</errata-url>
        <doi>10.17487/RFC3971</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Secure Neighbor Discovery</kw>
            <kw>SEND</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-send-cga-06</draft>
        <updated-by>
            <doc-id>RFC4581</doc-id>
            <doc-id>RFC4982</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>send</wg_acronym>
        <doi>10.17487/RFC3972</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>multicast routing protocol</kw>
            <kw>prune messages</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pim-dm-new-v2-05</draft>
        <updated-by>
            <doc-id>RFC8736</doc-id>
            <doc-id>RFC9436</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3973</errata-url>
        <doi>10.17487/RFC3973</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>simple mail transfer protocol</kw>
            <kw>dual stack</kw>
            <kw>dualstack</kw>
            <kw>ipv4</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>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.</p><p> This document does not define any new protocol. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-motonori-dualstack-smtp-requirement-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3974</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>oopen mobile alliance</kw>
            <kw>ietf</kw>
            <kw>internet engineering task force</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-iab-oma-liaison-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC3975</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-gurbani-sin-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3976</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3977</doc-id>
        <title>Network News Transfer Protocol (NNTP)</title>
        <author>
            <name>C. Feather</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>125</page-count>
        <keywords>
            <kw>usenet</kw>
            <kw>netnews</kw>
        </keywords>
        <abstract><p>The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today.  This document is a replacement for RFC 977, and officially updates the protocol specification.  It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nntpext-base-27</draft>
        <obsoletes>
            <doc-id>RFC0977</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2980</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6048</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>nntpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3977</errata-url>
        <doi>10.17487/RFC3977</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Intellectual Property Rights</kw>
            <kw>IPR</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipr-subm-rights-fix-00</draft>
        <obsoletes>
            <doc-id>RFC3667</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5378</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4748</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3978</errata-url>
        <doi>10.17487/RFC3978</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPR</kw>
            <kw>Intellectual Property Rights</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <obsoletes>
            <doc-id>RFC3668</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8179</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2026</doc-id>
            <doc-id>RFC2028</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4879</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <doi>10.17487/RFC3979</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet small computer systems interface</kw>
            <kw>scsi transport protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ips-iscsi-name-ext-05</draft>
        <obsoleted-by>
            <doc-id>RFC7143</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3720</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC3980</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-crisp-iris-core-07</draft>
        <updated-by>
            <doc-id>RFC4992</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3981</errata-url>
        <doi>10.17487/RFC3981</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-crisp-iris-dreg-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3982</errata-url>
        <doi>10.17487/RFC3982</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-crisp-iris-beep-07</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <doi>10.17487/RFC3983</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>ITU-T Recommendation H.264</kw>
            <kw>ISO/IEC International Standard 14496-10</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-h264-11</draft>
        <obsoleted-by>
            <doc-id>RFC6184</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC3984</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pwe3-arch-07</draft>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC3985</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>Internet protocol</kw>
            <kw>IP</kw>
            <kw>uniform resource identifier</kw>
            <kw>URI</kw>
            <kw>www</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <updated-by>
            <doc-id>RFC6874</doc-id>
            <doc-id>RFC7320</doc-id>
            <doc-id>RFC8820</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0066</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3986</errata-url>
        <doi>10.17487/RFC3986</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>uri</kw>
            <kw>uniform resource identifier</kw>
            <kw>Universal Character Set</kw>
        </keywords>
        <abstract><p>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of 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.</p><p> 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.</p></abstract>
        <draft>draft-duerst-iri-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3987</errata-url>
        <doi>10.17487/RFC3987</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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.  This document specifies experimental extensions to LDP in support of LSP MTU discovery.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-ldp-mtu-extensions-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC3988</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>nat</kw>
            <kw>network address translator</kw>
            <kw>firewall</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-midcom-semantics-08</draft>
        <obsoleted-by>
            <doc-id>RFC5189</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <doi>10.17487/RFC3989</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-capwap-problem-statement-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC3990</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>voice</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-foster-mgcp-redirect-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3991</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>fault recovery</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-foster-mgcp-lockstep-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC3992</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-subscriber-id-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC3993</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>im</kw>
            <kw>status message content type</kw>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-simple-iscomposing-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC3994</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>optional</kw>
            <kw>subscription events</kw>
            <kw>subscription objects</kw>
            <kw>asynchronous even notification</kw>
        </keywords>
        <abstract><p>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).</p><p> 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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3995</errata-url>
        <doi>10.17487/RFC3995</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>pull delivery method</kw>
            <kw>event notifications</kw>
            <kw>event subscriptions</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3996</errata-url>
        <doi>10.17487/RFC3996</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>model</kw>
            <kw>directory services</kw>
            <kw>notification requirements</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-ipp-not-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <doi>10.17487/RFC3997</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-ipp-ops-set2-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ipp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc3998</errata-url>
        <doi>10.17487/RFC3998</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3999</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4000</doc-id>
    </rfc-not-issued-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>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>internet network layer addressing information</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4001</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>URI schemes</kw>
            <kw>uniform resource identifier</kw>
            <kw>enum</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-enum-webft-01</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4002</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>lsp</kw>
            <kw>label switch path</kw>
            <kw>gmpls signaling</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-egress-control-03</draft>
        <updates>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4004</doc-id>
        <title>Diameter Mobile IPv4 Application</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>T. Johansson</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>T. Hiller</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. McCann</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>internet protocol version 4</kw>
            <kw>aaa</kw>
            <kw>authentication authorization accounting</kw>
            <kw>inter-realm</kw>
            <kw>diameter accounting</kw>
        </keywords>
        <abstract><p>This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node.  Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers.  Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-aaa-diameter-mobileip-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4004</errata-url>
        <doi>10.17487/RFC4004</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4005</doc-id>
        <title>Diameter Network Access Server Application</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>D. Spence</name>
        </author>
        <author>
            <name>D. Mitton</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>aaa</kw>
            <kw>authentication authorization accounting</kw>
            <kw>nas</kw>
            <kw>diameter base</kw>
            <kw>transport profile</kw>
            <kw>extensible authentication protocol</kw>
            <kw>radius</kw>
        </keywords>
        <abstract><p>This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.</p><p> Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.</p><p> The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-aaa-diameter-nasreq-17</draft>
        <obsoleted-by>
            <doc-id>RFC7155</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4005</errata-url>
        <doi>10.17487/RFC4005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4006</doc-id>
        <title>Diameter Credit-Control Application</title>
        <author>
            <name>H. Hakala</name>
        </author>
        <author>
            <name>L. Mattila</name>
        </author>
        <author>
            <name>J-P. Koskinen</name>
        </author>
        <author>
            <name>M. Stura</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>114</page-count>
        <keywords>
            <kw>real-time credit-control</kw>
        </keywords>
        <abstract><p>This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-aaa-diameter-cc-06</draft>
        <obsoleted-by>
            <doc-id>RFC8506</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4006</errata-url>
        <doi>10.17487/RFC4006</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>architectural characteristics</kw>
            <kw>expected behavior</kw>
            <kw>textual representation</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipv6-scoping-arch-02</draft>
        <updated-by>
            <doc-id>RFC7346</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4007</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-nat-natmib-09</draft>
        <obsoleted-by>
            <doc-id>RFC7658</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4008</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>encryption algorithm</kw>
            <kw>seed cbc</kw>
            <kw>seed oid</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-park-seed-01</draft>
        <obsoleted-by>
            <doc-id>RFC4269</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4009</errata-url>
        <doi>10.17487/RFC4009</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>smime</kw>
            <kw>secure/multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).</p><p> 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]</p></abstract>
        <draft>draft-ietf-smime-cms-seed-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4010</errata-url>
        <doi>10.17487/RFC4010</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>121</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-snmpconf-pm-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>snmpconf</wg_acronym>
        <doi>10.17487/RFC4011</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-blunk-rpslng-08</draft>
        <updates>
            <doc-id>RFC2725</doc-id>
            <doc-id>RFC2622</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7909</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4012</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>unicode strings</kw>
            <kw>saslprep</kw>
            <kw>stringprep</kw>
            <kw>sasl</kw>
            <kw>simple authentication and security layer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sasl-saslprep-10</draft>
        <obsoleted-by>
            <doc-id>RFC7613</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4013</errata-url>
        <doi>10.17487/RFC4013</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-agentopt-radius-08</draft>
        <updated-by>
            <doc-id>RFC9445</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4014</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>transmision control protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-tsvwg-tcp-eifel-response-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4015</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>network access</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pana-threats-eval-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pana</wg_acronym>
        <doi>10.17487/RFC4016</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IEEE 802.11</kw>
            <kw>wireless lan</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-walker-ieee802-req-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4017</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>scsi</kw>
            <kw>slp</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ips-iscsi-slp-09</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC4018</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-rohc-udp-lite-04</draft>
        <updated-by>
            <doc-id>RFC4815</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4019</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-kompella-zinin-early-allocation-02</draft>
        <obsoleted-by>
            <doc-id>RFC7120</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4020</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-klyne-hdrreg-mail-05</draft>
        <updated-by>
            <doc-id>RFC5322</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4021</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MIB-TCP</kw>
            <kw>TCP</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4022</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mpls-in-ip-or-gre-08</draft>
        <updated-by>
            <doc-id>RFC5332</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4024</doc-id>
        <title>Voice Messaging Client Behaviour</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Maruszak</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>vpim</kw>
            <kw>profile</kw>
            <kw>internet mail</kw>
            <kw>voice profile for internet mail</kw>
            <kw>fax message</kw>
        </keywords>
        <abstract><p>This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ema-vpim-cb-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4024</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>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.</p><p> This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipseckey-rr-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipseckey</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4025</errata-url>
        <doi>10.17487/RFC4025</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>l3vpn</kw>
            <kw>l2vpn</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p></abstract>
        <draft>draft-ietf-l3vpn-ppvpn-terminology-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4026</errata-url>
        <doi>10.17487/RFC4026</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>media type</kw>
            <kw>application/dns</kw>
            <kw>text/dns</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-josefsson-mime-dns-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4027</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>re-invite request</kw>
            <kw>update request</kw>
            <kw>session-expires</kw>
            <kw>min-se</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-sip-session-timer-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4028</errata-url>
        <doi>10.17487/RFC4028</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>internet service provider</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-isp-scenarios-analysis-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4029</errata-url>
        <doi>10.17487/RFC4029</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-auth-suboption-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4030</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>l3vpn</kw>
            <kw>service provider</kw>
            <kw>vpn</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-l3vpn-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC4031</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>precondition</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4032</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <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><p>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]</p></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>RFC3597</doc-id>
            <doc-id>RFC3226</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6014</doc-id>
            <doc-id>RFC6840</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4033</errata-url>
        <doi>10.17487/RFC4033</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <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><p>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.</p><p> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</p></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>RFC3597</doc-id>
            <doc-id>RFC3226</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4470</doc-id>
            <doc-id>RFC6014</doc-id>
            <doc-id>RFC6840</doc-id>
            <doc-id>RFC6944</doc-id>
            <doc-id>RFC9077</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4034</errata-url>
        <doi>10.17487/RFC4034</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <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><p>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.</p><p> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</p></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>RFC3597</doc-id>
            <doc-id>RFC3226</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4470</doc-id>
            <doc-id>RFC6014</doc-id>
            <doc-id>RFC6840</doc-id>
            <doc-id>RFC8198</doc-id>
            <doc-id>RFC9077</doc-id>
            <doc-id>RFC9520</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4035</errata-url>
        <doi>10.17487/RFC4035</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-ipcdn-subscriber-mib-16</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4036</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>callout server</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-opes-ocp-core-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC4037</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-v6ops-application-transition-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4038</errata-url>
        <doi>10.17487/RFC4038</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-dhc-rapid-commit-opt-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4039</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>realtime transport protocol</kw>
        </keywords>
        <abstract><p>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".</p><p> "Clearmode" is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-clearmode-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4040</doi>
    </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>1</day>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>moral values</kw>
            <kw>moral code</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p></abstract>
        <draft>draft-farrel-rtg-morality-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4041</doi>
    </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>1</day>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <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><p>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.</p><p> 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.</p><p> 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.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4042</errata-url>
        <doi>10.17487/RFC4042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4043</doc-id>
        <title>Internet X.509 Public Key Infrastructure Permanent Identifier</title>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>T. Gindin</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>subjectAltName extension</kw>
            <kw>dn</kw>
        </keywords>
        <abstract><p>This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.</p><p> The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.</p><p> The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-pi-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4043</errata-url>
        <doi>10.17487/RFC4043</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>fc-mgmt-mib</kw>
        </keywords>
        <abstract><p>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]</p></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>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC4044</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>ppp</kw>
            <kw>point-to-point protocol</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-l2tpext-mcast-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC4045</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>group security association</kw>
            <kw>gsa</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-msec-gkmarch-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4046</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>multipurpose internet mail extensions</kw>
            <kw>astronomical observations</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-allen-fitsmime-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4047</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Open</kw>
            <kw>Systems</kw>
            <kw>Interconnection</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-carpenter-obsolete-1888-01</draft>
        <obsoletes>
            <doc-id>RFC1888</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4548</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4048</errata-url>
        <doi>10.17487/RFC4048</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>signing-time attribute</kw>
            <kw>cryptographic message syntax</kw>
            <kw>cms</kw>
            <kw>SignedData</kw>
            <kw>AuthenticatedData</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-housley-binarytime-02</draft>
        <obsoleted-by>
            <doc-id>RFC6019</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4049</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-blake-wilson-xmldsig-ecdsa-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4050</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>digital signatures</kw>
            <kw>encryption</kw>
            <kw>canonicalization</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-eastlake-xmldsig-uri-09</draft>
        <obsoleted-by>
            <doc-id>RFC6931</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4051</errata-url>
        <doi>10.17487/RFC4051</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>sdo</kw>
            <kw>standards development organization</kw>
        </keywords>
        <abstract><p>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.</p></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>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4052</errata-url>
        <doi>10.17487/RFC4052</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>sdo</kw>
            <kw>standards development organization</kw>
        </keywords>
        <abstract><p>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.</p><p> 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.</p></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>
        <stream>IAB</stream>
        <doi>10.17487/RFC4053</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <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><p>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.</p></abstract>
        <draft>draft-ietf-ipo-impairments-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>ipo</wg_acronym>
        <doi>10.17487/RFC4054</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4055</doc-id>
        <title>Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ASN.1</kw>
            <kw>RSASSA-PSS</kw>
            <kw>RSA probabilistic signature scheme</kw>
            <kw>signature algorithm</kw>
            <kw>RSAES-OAEP</kw>
            <kw>RSA encryption scheme optimal asymmetric encryption padding</kw>
            <kw>public-key cryptography standards</kw>
            <kw>PKCS</kw>
            <kw>pki</kw>
        </keywords>
        <abstract><p>This document supplements RFC 3279.  It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rsa-pkalgs-03</draft>
        <updates>
            <doc-id>RFC3279</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4055</errata-url>
        <doi>10.17487/RFC4055</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4056</doc-id>
        <title>Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>RSA probabilistic signature scheme</kw>
            <kw>digital signature</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-pss-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4056</errata-url>
        <doi>10.17487/RFC4056</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4057</doc-id>
        <title>IPv6 Enterprise Network Scenarios</title>
        <author>
            <name>J. Bound</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This document describes the scenarios for IPv6 deployment within enterprise networks.  It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.  Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.  The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment.  The results of that analysis will be published in a separate document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-ent-scenarios-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4057</errata-url>
        <doi>10.17487/RFC4057</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4058</doc-id>
        <title>Protocol for Carrying Authentication for Network Access (PANA) Requirements</title>
        <author>
            <name>A. Yegin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>C. Wang</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>network connectivity</kw>
            <kw>link layer agnostic protocol</kw>
        </keywords>
        <abstract><p>It is expected that future IP devices will have a variety of access technologies to gain network connectivity.  Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes.  In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links).  The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access.  This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pana-requirements-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pana</wg_acronym>
        <doi>10.17487/RFC4058</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>certificate authority</kw>
            <kw>ca</kw>
            <kw>insurance policy</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-pkix-warranty-extn-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4059</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <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><p>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]</p></abstract>
        <draft>draft-ietf-avt-rtp-dsr-codecs-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4060</errata-url>
        <doi>10.17487/RFC4060</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>spf time</kw>
            <kw>adjacency formation time</kw>
        </keywords>
        <abstract><p>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.</p><p> NOTE: In this document, the word "convergence" relates to single router control plane convergence only. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-ospfconv-intraarea-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4061</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>spf time</kw>
            <kw>adjacency formation time</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-ospfconv-term-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4062</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>spf time</kw>
            <kw>adjacency formation time</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-bmwg-ospfconv-applicability-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4063</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4064</doc-id>
        <title>Experimental Message, Extensions, and Error Codes for Mobile IPv4</title>
        <author>
            <name>A. Patel</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>message types</kw>
        </keywords>
        <abstract><p>Mobile IPv4 message types range from 0 to 255.  This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-experimental-messages-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC4064</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4065</doc-id>
        <title>Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>candidate access router discovery</kw>
            <kw>card</kw>
            <kw>context transfer protocol</kw>
            <kw>CXTP</kw>
            <kw>ICMP</kw>
        </keywords>
        <abstract><p>The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers.  These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options.  This document contains instructions to IANA about which allocations are required for the Seamoby protocols.  The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-seamoby-iana-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC4065</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4066</doc-id>
        <title>Candidate Access Router Discovery (CARD)</title>
        <author>
            <name>M. Liebsch</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Singh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Chaskar</name>
        </author>
        <author>
            <name>D. Funato</name>
        </author>
        <author>
            <name>E. Shim</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>mobile node</kw>
            <kw>mn</kw>
            <kw>cars</kw>
            <kw>candidate ars</kw>
        </keywords>
        <abstract><p>To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover.  The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities.  This process is called "candidate access router discovery" (CARD).  At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover.  The protocol described in this document allows a mobile node to perform CARD.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-seamoby-card-protocol-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC4066</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4067</doc-id>
        <title>Context Transfer Protocol (CXTP)</title>
        <author>
            <name>J. Loughney</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nakhjiri</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>mobile node</kw>
            <kw>mn</kw>
        </keywords>
        <abstract><p>This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers.  Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption.  Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-seamoby-ctp-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>seamoby</wg_acronym>
        <doi>10.17487/RFC4067</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4068</doc-id>
        <title>Fast Handovers for Mobile IPv6</title>
        <author>
            <name>R. Koodli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>access router</kw>
            <kw>mobile node</kw>
            <kw>mn</kw>
        </keywords>
        <abstract><p>Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover.  During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations.  This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP.  Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well.  This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures.  This document does not address improving the link switching latency.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-fast-mipv6-03</draft>
        <obsoleted-by>
            <doc-id>RFC5268</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC4068</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>VDSL-LINE-MIB</kw>
            <kw>VDSL-LINE-EXT-SCM-MIB</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-adslmib-vdsl-ext-scm-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4069</errata-url>
        <doi>10.17487/RFC4069</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>VDSL-LINE-MIB</kw>
            <kw>VDSL-LINE-EXT-MCM-MIB</kw>
        </keywords>
        <abstract><p>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. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-adslmib-vdsl-ext-mcm-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <doi>10.17487/RFC4070</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>isoc</kw>
            <kw>ietf administrative oversight committee</kw>
            <kw>IAOC</kw>
            <kw>ietf administrative director</kw>
            <kw>iad</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-iasa-bcp-07</draft>
        <obsoleted-by>
            <doc-id>RFC8711</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4371</doc-id>
            <doc-id>RFC7691</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4071</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4072</doc-id>
        <title>Diameter Extensible Authentication Protocol (EAP) Application</title>
        <author>
            <name>P. Eronen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Hiller</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>command codes</kw>
            <kw>avp</kw>
            <kw>nas</kw>
            <kw>network access server</kw>
            <kw>back-end autentication server</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods.  This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-aaa-eap-10</draft>
        <updated-by>
            <doc-id>RFC7268</doc-id>
            <doc-id>RFC8044</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4072</errata-url>
        <doi>10.17487/RFC4072</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>content collection</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-housley-contentcollection-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4073</errata-url>
        <doi>10.17487/RFC4073</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4074</doc-id>
        <title>Common Misbehavior Against DNS Queries for IPv6 Addresses</title>
        <author>
            <name>Y. Morishita</name>
        </author>
        <author>
            <name>T. Jinmei</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>resource records</kw>
            <kw>aaaa</kw>
            <kw>domain name service</kw>
        </keywords>
        <abstract><p>There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records.  Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack.  This memo describes details of known cases and discusses their effects.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsop-misbehavior-against-aaaa-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC4074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4075</doc-id>
        <title>Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6</title>
        <author>
            <name>V. Kalusivalingam</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
            <kw>server addresses</kw>
        </keywords>
        <abstract><p>This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-opt-sntp-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4075</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4076</doc-id>
        <title>Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>A. Vijayabhaskar</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>stateless address autoconfiguration</kw>
        </keywords>
        <abstract><p>IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically.  However, further settings are not available.  If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used.  This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.  However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering.  This document is presented as a problem statement from which a solution should be proposed in a subsequent document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dhc-stateless-dhcpv6-renumbering-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4077</doc-id>
        <title>A Negative Acknowledgement Mechanism for Signaling Compression</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>sigcomp</kw>
            <kw>negative feedback</kw>
        </keywords>
        <abstract><p>This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed.  This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-sigcomp-nack-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4077</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4078</doc-id>
        <title>The TV-Anytime Content Reference Identifier (CRID)</title>
        <author>
            <name>N. Earnshaw</name>
        </author>
        <author>
            <name>S. Aoki</name>
        </author>
        <author>
            <name>A. Ashley</name>
        </author>
        <author>
            <name>W. Kameyama</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>digital broadcasting</kw>
            <kw>tv</kw>
            <kw>radio</kw>
            <kw>uri</kw>
            <kw>uniform resource identifier</kw>
            <kw>content referencing</kw>
            <kw>storage systems</kw>
        </keywords>
        <abstract><p>The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.</p><p> The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.</p><p> This document reproduces the \%TV-Anytime CRID definition found in the \%TV-Anytime content referencing specification, 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.</p></abstract>
        <draft>draft-earnshaw-tv-anytime-crid-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4079</doc-id>
        <title>A Presence Architecture for the Distribution of GEOPRIV Location Objects</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>using protocol</kw>
        </keywords>
        <abstract><p>GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects.  GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications.  This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-geopriv-pres-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC4079</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4080</doc-id>
        <title>Next Steps in Signaling (NSIS): Framework</title>
        <author>
            <name>R. Hancock</name>
        </author>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>S. Van den Bosch</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>data flow</kw>
            <kw>architectural framework</kw>
            <kw>signaling protocols</kw>
            <kw>signaling application</kw>
        </keywords>
        <abstract><p>The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.</p><p> This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-fw-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC4080</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4081</doc-id>
        <title>Security Threats for Next Steps in Signaling (NSIS)</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Kroeselberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite.  It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals.  This document does not describe vulnerabilities of specific parts of the NSIS protocol suite.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-threats-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC4081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4082</doc-id>
        <title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction</title>
        <author>
            <name>A. Perrig</name>
        </author>
        <author>
            <name>D. Song</name>
        </author>
        <author>
            <name>R. Canetti</name>
        </author>
        <author>
            <name>J. D. Tygar</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>data streams</kw>
        </keywords>
        <abstract><p>This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.</p><p> This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-msec-tesla-intro-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4082</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4083</doc-id>
        <title>Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>3GPP IP multimedia core network subsystem</kw>
            <kw>ims</kw>
            <kw>cellular networks</kw>
        </keywords>
        <abstract><p>The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS).  IMS is part of Release 5 of the 3GPP specifications.  Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network.  In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-3gpp-r5-requirements-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4083</doi>
    </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>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>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.</p></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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4084</errata-url>
        <doi>10.17487/RFC4084</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4085</doc-id>
        <title>Embedding Globally-Routable Internet Addresses Considered Harmful</title>
        <author>
            <name>D. Plonka</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives.  This document is intended to clarify best current practices in this regard.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-grow-embed-addr-05</draft>
        <is-also>
            <doc-id>BCP0105</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC4085</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4086</doc-id>
        <title>Randomness Requirements for Security</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>J. Schiller</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>cryptographic algorithms</kw>
            <kw>passwords</kw>
            <kw>cryptographic keys</kw>
            <kw>pseudo-random</kw>
            <kw>random</kw>
            <kw>numbers</kw>
            <kw>seed</kw>
        </keywords>
        <abstract><p>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</p><p> Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating 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. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-eastlake-randomness2-10</draft>
        <obsoletes>
            <doc-id>RFC1750</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0106</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4086</errata-url>
        <doi>10.17487/RFC4086</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4087</doc-id>
        <title>IP Tunnel MIB</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>internet protocol</kw>
            <kw>tunnel-mib</kw>
        </keywords>
        <abstract><p>This memo defines a Management Information Base (MIB) module 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 and IPv6 networks.  Extension MIB modules may be designed for managing protocol-specific objects.  Likewise, extension MIB modules may be designed for managing security-specific objects.  This MIB module does not support tunnels over non-IP networks.  Management of such tunnels may be supported by other MIB modules.  This memo obsoletes RFC 2667. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-inet-tunnel-mib-03</draft>
        <obsoletes>
            <doc-id>RFC2667</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4087</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4088</doc-id>
        <title>Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>uri</kw>
            <kw>uniform resource identifiers</kw>
            <kw>snmp-uri</kw>
        </keywords>
        <abstract><p>The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.</p><p> This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-black-snmp-uri-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4089</doc-id>
        <title>IAB and IESG Recommendation for IETF Administrative Restructuring</title>
        <author>
            <name>S. Hollenbeck</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB and IESG</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>internet engineering steering group</kw>
            <kw>internet engineering task force</kw>
        </keywords>
        <abstract><p>This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force.  The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004.  Further work has been done to revise and refine the structures proposed.  The recommendation is being published for the record.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-iesg-adminrest-rec-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4089</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4090</doc-id>
        <title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
        <author>
            <name>P. Pan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Atlas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>resource reservation protocol</kw>
            <kw>traffic engineering</kw>
            <kw>lsp</kw>
            <kw>label switch path</kw>
            <kw>one-to-one backup</kw>
            <kw>facility backup</kw>
        </keywords>
        <abstract><p>This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.</p><p> Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-rsvp-lsp-fastreroute-07</draft>
        <updated-by>
            <doc-id>RFC8271</doc-id>
            <doc-id>RFC8537</doc-id>
            <doc-id>RFC8796</doc-id>
            <doc-id>RFC9705</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4090</errata-url>
        <doi>10.17487/RFC4090</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4091</doc-id>
        <title>The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework.  The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-anat-02</draft>
        <obsoleted-by>
            <doc-id>RFC5245</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4091</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4092</doc-id>
        <title>Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>sdp-anat</kw>
            <kw>option-tag</kw>
        </keywords>
        <abstract><p>This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP.  In particular, we define the sdp-anat SIP option-tag.  This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support.  To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-anat-usage-00</draft>
        <obsoleted-by>
            <doc-id>RFC5245</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4092</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4093</doc-id>
        <title>Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways</title>
        <author>
            <name>F. Adrangi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Levkowetz</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions.  This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip4-vpn-problem-statement-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC4093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4094</doc-id>
        <title>Analysis of Existing Quality-of-Service Signaling Protocols</title>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>X. Fu</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>rsvp</kw>
            <kw>nsis</kw>
            <kw>yessir</kw>
            <kw>boomerang</kw>
            <kw>daris</kw>
            <kw>insignia</kw>
            <kw>bgrp</kw>
            <kw>sicap</kw>
            <kw>mobility</kw>
            <kw>performance</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network.  The goal here is to learn from them and to avoid common misconceptions.  Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-signalling-analysis-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC4094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4095</doc-id>
        <title>Attaching Meaning to Solicitation Class Keywords</title>
        <author>
            <name>C. Malamud</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>uri</kw>
            <kw>uniform resource identifier</kw>
            <kw>no soliciting smtp service extension</kw>
            <kw>esmtp service extension</kw>
            <kw>dynamic delegation discovery system</kw>
            <kw>ddds</kw>
            <kw>no-solicit</kw>
        </keywords>
        <abstract><p>This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.</p><p> This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-malamud-keyword-discovery-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4095</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4096</doc-id>
        <title>Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best</title>
        <author>
            <name>C. Malamud</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message.  Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best.  This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-malamud-subject-line-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4096</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4097</doc-id>
        <title>Middlebox Communications (MIDCOM) Protocol Evaluation</title>
        <author>
            <name>M. Barnes</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>rsip</kw>
            <kw>realm specific internet protocol</kw>
            <kw>megaco</kw>
            <kw>diameter</kw>
            <kw>cops</kw>
            <kw>common open policy service</kw>
        </keywords>
        <abstract><p>This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol.  A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided.  Compliancy of each of the protocols against each requirement is detailed.  A conclusion summarizes how each of the protocols fares in the evaluation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-midcom-protocol-eval-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <doi>10.17487/RFC4097</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4098</doc-id>
        <title>Terminology for Benchmarking BGP Device Convergence in the Control Plane</title>
        <author>
            <name>H. Berkowitz</name>
        </author>
        <author>
            <name>E. Davies</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>P. Krishnaswamy</name>
        </author>
        <author>
            <name>M. Lepp</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>benchmarking methodology</kw>
            <kw>ebgp</kw>
        </keywords>
        <abstract><p>This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device.  Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6.  Illustrative examples of each version are included where relevant.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-conterm-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4098</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4099</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4100</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4101</doc-id>
        <title>Writing Protocol Models</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>document review</kw>
        </keywords>
        <abstract><p>The IETF process depends on peer review.  However, IETF documents are generally written to be useful for implementors, not reviewers.  In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding.  This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-model-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4101</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4102</doc-id>
        <title>Registration of the text/red MIME Sub-Type</title>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>rtp</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>This document defines the text/red MIME sub-type. "Red" is short for redundant.  The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-text-red-05</draft>
        <updated-by>
            <doc-id>RFC6354</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4102</errata-url>
        <doi>10.17487/RFC4102</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4103</doc-id>
        <title>RTP Payload for Text Conversation</title>
        <author>
            <name>G. Hellstrom</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>applications</kw>
            <kw>video</kw>
            <kw>audio</kw>
            <kw>packets</kw>
        </keywords>
        <abstract><p>This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.</p><p> One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.</p><p> This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc2793bis-09</draft>
        <obsoletes>
            <doc-id>RFC2793</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9071</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4103</errata-url>
        <doi>10.17487/RFC4103</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4104</doc-id>
        <title>Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)</title>
        <author>
            <name>M. Pana</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Reyes</name>
        </author>
        <author>
            <name>A. Barba</name>
        </author>
        <author>
            <name>D. Moron</name>
        </author>
        <author>
            <name>M. Brunner</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>policy core lightweight directory access protocol</kw>
            <kw>pcim</kw>
            <kw>policy core information model</kw>
            <kw>mapping classes</kw>
        </keywords>
        <abstract><p>This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460).  These changes and extensions consist of new LDAP object classes and attribute types.  Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460.  The other schema items implement new concepts, not covered by RFC 3703.  This document updates RFC 3703. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-reyes-policy-core-ext-schema-07</draft>
        <updates>
            <doc-id>RFC3703</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4104</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4105</doc-id>
        <title>Requirements for Inter-Area MPLS Traffic Engineering</title>
        <author>
            <name>J.-L. Le Roux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J.-P. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Boyle</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpls-te</kw>
            <kw>mpls te</kw>
        </keywords>
        <abstract><p>This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).  It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tewg-interarea-mpls-te-req-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC4105</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4106</doc-id>
        <title>The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)</title>
        <author>
            <name>J. Viega</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>aes</kw>
            <kw>advanced encryption standard</kw>
        </keywords>
        <abstract><p>This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication.  This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-ciph-aes-gcm-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4106</errata-url>
        <doi>10.17487/RFC4106</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4107</doc-id>
        <title>Guidelines for Cryptographic Key Management</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>automated key management</kw>
            <kw>manual key management</kw>
        </keywords>
        <abstract><p>The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient.  This memo provides guidelines for making such decisions.  When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed.  If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-bellovin-mandate-keymgmt-03</draft>
        <is-also>
            <doc-id>BCP0107</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4107</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4108</doc-id>
        <title>Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>hardward module components</kw>
            <kw>digital signature</kw>
        </keywords>
        <abstract><p>This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components.  CMS is specified in RFC 3852.  A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication.  Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package.  A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package.  Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-housley-cms-fw-wrap-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4108</errata-url>
        <doi>10.17487/RFC4108</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4109</doc-id>
        <title>Algorithms for Internet Key Exchange version 1 (IKEv1)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ike</kw>
            <kw>ipsec</kw>
            <kw>oakley</kw>
            <kw>authentication</kw>
            <kw>isakmp</kw>
            <kw>internet security key management</kw>
        </keywords>
        <abstract><p>The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements.  The original specification allows weak security and suggests algorithms that are thinly implemented.  This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hoffman-ikev1-algorithms-03</draft>
        <updates>
            <doc-id>RFC2409</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4109</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4110</doc-id>
        <title>A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)</title>
        <author>
            <name>R. Callon</name>
        </author>
        <author>
            <name>M. Suzuki</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <abstract><p>This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs).  This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs.  It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions.  Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l3vpn-framework-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4110</errata-url>
        <doi>10.17487/RFC4110</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4111</doc-id>
        <title>Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)</title>
        <author>
            <name>L. Fang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <abstract><p>This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs).  First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats.  It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers.  It also describes how these security attacks should be detected and reported.  It then discusses possible user requirements for security of a PPVPN service.  These user requirements translate into corresponding provider requirements.  In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations.  Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l3vpn-security-framework-03</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4111</errata-url>
        <doi>10.17487/RFC4111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4112</doc-id>
        <title>Electronic Commerce Modeling Language (ECML) Version 2 Specification</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate.  A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated.  This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-trade-ecml2-spec-13</draft>
        <updates>
            <doc-id>RFC3106</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC4112</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4113</doc-id>
        <title>Management Information Base for the User Datagram Protocol (UDP)</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MIB-UDP|p</kw>
            <kw>mib</kw>
            <kw>Management Information Base</kw>
            <kw>UDP-MIB</kw>
            <kw>internet protocol</kw>
            <kw>ip</kw>
        </keywords>
        <abstract><p>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 User Datagram Protocol (UDP) in an IP version independent manner.  This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-rfc2013-update-04</draft>
        <obsoletes>
            <doc-id>RFC2454</doc-id>
            <doc-id>RFC2013</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4113</errata-url>
        <doi>10.17487/RFC4113</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4114</doc-id>
        <title>E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>shared central repository</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-epp-e164-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4114</errata-url>
        <doi>10.17487/RFC4114</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4115</doc-id>
        <title>A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic</title>
        <author>
            <name>O. Aboul-Magd</name>
        </author>
        <author>
            <name>S. Rabie</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>data services</kw>
            <kw>service scenarios</kw>
            <kw>metering algorithm</kw>
            <kw>color-blind</kw>
            <kw>color-aware</kw>
        </keywords>
        <abstract><p>This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services.  This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services.  The marker defined here is different from previously defined markers in the handling of the in-profile traffic.  Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-aboulmagd-trtcm-inprofile-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4115</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4116</doc-id>
        <title>IPv4 Multihoming Practices and Limitations</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>K. Lindqvist</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>B. Black</name>
        </author>
        <author>
            <name>V. Gill</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>Multihoming is an essential component of service for many Internet sites.  This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-multi6-v4-multihoming-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>multi6</wg_acronym>
        <doi>10.17487/RFC4116</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4117</doc-id>
        <title>Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>A. van Wijk</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>deaf</kw>
            <kw>hard of hearing</kw>
            <kw>speech-impaired</kw>
            <kw>hearing-impaired</kw>
        </keywords>
        <abstract><p>This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control.  This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-transc-3pcc-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4117</errata-url>
        <doi>10.17487/RFC4117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4118</doc-id>
        <title>Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)</title>
        <author>
            <name>L. Yang</name>
        </author>
        <author>
            <name>P. Zerfos</name>
        </author>
        <author>
            <name>E. Sadot</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>IEEE 802.11</kw>
            <kw>wireless lan</kw>
        </keywords>
        <abstract><p>This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-capwap-arch-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC4118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4119</doc-id>
        <title>A Presence-based GEOPRIV Location Object Format</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>pidf</kw>
            <kw>presence information data format</kw>
        </keywords>
        <abstract><p>This document describes an object format for carrying geographical information on the Internet.  This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-pidf-lo-03</draft>
        <updated-by>
            <doc-id>RFC5139</doc-id>
            <doc-id>RFC5491</doc-id>
            <doc-id>RFC7459</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4119</errata-url>
        <doi>10.17487/RFC4119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4120</doc-id>
        <title>The Kerberos Network Authentication Service (V5)</title>
        <author>
            <name>C. Neuman</name>
        </author>
        <author>
            <name>T. Yu</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>K. Raeburn</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>138</page-count>
        <keywords>
            <kw>KERBEROS</kw>
            <kw>CAT</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510.  This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-kerberos-clarifications-07</draft>
        <obsoletes>
            <doc-id>RFC1510</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4537</doc-id>
            <doc-id>RFC5021</doc-id>
            <doc-id>RFC5896</doc-id>
            <doc-id>RFC6111</doc-id>
            <doc-id>RFC6112</doc-id>
            <doc-id>RFC6113</doc-id>
            <doc-id>RFC6649</doc-id>
            <doc-id>RFC6806</doc-id>
            <doc-id>RFC7751</doc-id>
            <doc-id>RFC8062</doc-id>
            <doc-id>RFC8129</doc-id>
            <doc-id>RFC8429</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4120</errata-url>
        <doi>10.17487/RFC4120</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4121</doc-id>
        <title>The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>GSSAPI-KER</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract><p>This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism.</p><p> RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-gssapi-cfx-07</draft>
        <updates>
            <doc-id>RFC1964</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5896</doc-id>
            <doc-id>RFC6112</doc-id>
            <doc-id>RFC6542</doc-id>
            <doc-id>RFC6649</doc-id>
            <doc-id>RFC8062</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC4121</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4122</doc-id>
        <title>A Universally Unique IDentifier (UUID) URN Namespace</title>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <author>
            <name>R. Salz</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>uniform resource name</kw>
            <kw>guid</kw>
            <kw>globally unique identifier</kw>
        </keywords>
        <abstract><p>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</p><p> This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mealling-uuid-urn-05</draft>
        <obsoleted-by>
            <doc-id>RFC9562</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4122</errata-url>
        <doi>10.17487/RFC4122</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4123</doc-id>
        <title>Session Initiation Protocol (SIP)-H.323 Interworking Requirements</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>C. Agboh</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SIP-H.323 IWF</kw>
        </keywords>
        <abstract><p>This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-agrawal-sip-h323-interworking-reqs-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4123</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4124</doc-id>
        <title>Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering</title>
        <author>
            <name>F. Le Faucheur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>DS-TE</kw>
            <kw>igp</kw>
            <kw>interior gateway protocol</kw>
            <kw>extensions</kw>
            <kw>rsvp</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE).  This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those.  This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering.  These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tewg-diff-te-proto-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC4124</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4125</doc-id>
        <title>Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>W. Lai</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ds-te</kw>
            <kw>maximum allocation model</kw>
        </keywords>
        <abstract><p>This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tewg-diff-te-mam-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC4125</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4126</doc-id>
        <title>Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering &amp; Performance Comparisons</title>
        <author>
            <name>J. Ash</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>diffserv-enabled mpls traffic engineering</kw>
            <kw>ds-te</kw>
            <kw>mar</kw>
            <kw>bandwidth reservation</kw>
            <kw>bandwidth allocation</kw>
            <kw>bandwidth protection</kw>
            <kw>performance evaluation</kw>
            <kw>cac</kw>
            <kw>network model</kw>
        </keywords>
        <abstract><p>This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model.  Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented.  MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tewg-diff-te-mar-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC4126</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4127</doc-id>
        <title>Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering</title>
        <author>
            <name>F. Le Faucheur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ds-te</kw>
            <kw>russian dolls model</kw>
            <kw>multi-protocol label switching</kw>
        </keywords>
        <abstract><p>This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tewg-diff-te-russian-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC4127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4128</doc-id>
        <title>Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation</title>
        <author>
            <name>W. Lai</name>
        </author>
        <date>
            <month>June</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>label switched path</kw>
            <kw>lsp</kw>
            <kw>lsp blocking</kw>
            <kw>lsp preemption</kw>
            <kw>lsp priority traffic overload</kw>
            <kw>bandwidth efficiency</kw>
            <kw>bandwidth sharing</kw>
            <kw>bandwidth protection</kw>
            <kw>class isolation</kw>
            <kw>maximum allocation model</kw>
            <kw>russian dolls model</kw>
        </keywords>
        <abstract><p>"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models.  Two such models, the Maximum Allocation and the Russian Dolls, are described therein.  This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-wlai-tewg-bcmodel-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4128</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4129</doc-id>
        <title>Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol</title>
        <author>
            <name>R. Mukundan</name>
        </author>
        <author>
            <name>K. Morneault</name>
        </author>
        <author>
            <name>N. Mangalpally</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>backhauling</kw>
            <kw>isdn user adaptation</kw>
            <kw>pbx</kw>
            <kw>private branch exchanges</kw>
        </keywords>
        <abstract><p>This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057.  DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network.  DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.  This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sigtran-dua-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC4129</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4130</doc-id>
        <title>MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)</title>
        <author>
            <name>D. Moberg</name>
        </author>
        <author>
            <name>R. Drummond</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>hyper text transfer protocol</kw>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract><p>This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335.  Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats.  The data is packaged using standard MIME structures.  Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts.  Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message.  This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ediint-as2-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ediint</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4130</errata-url>
        <doi>10.17487/RFC4130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4131</doc-id>
        <title>Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus</title>
        <author>
            <name>S. Green</name>
        </author>
        <author>
            <name>K. Ozawa</name>
        </author>
        <author>
            <name>E. Cardona</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Katsnelson</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>docs-ietf-bpi2-mib</kw>
        </keywords>
        <abstract><p>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 the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-bpiplus-mib-15</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4131</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4132</doc-id>
        <title>Addition of Camellia Cipher Suites to Transport Layer Security (TLS)</title>
        <author>
            <name>S. Moriai</name>
        </author>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>M. Kanda</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>camellia encryption algorithm</kw>
        </keywords>
        <abstract><p>This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-camellia-06</draft>
        <obsoleted-by>
            <doc-id>RFC5932</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC4132</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4133</doc-id>
        <title>Entity MIB (Version 3)</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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.  This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-entmib-v3-07</draft>
        <obsoletes>
            <doc-id>RFC2737</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6933</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>entmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4133</errata-url>
        <doi>10.17487/RFC4133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4134</doc-id>
        <title>Examples of S/MIME Messages</title>
        <author>
            <name>P. Hoffman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>136</page-count>
        <abstract><p>This document gives examples of message bodies formatted using S/MIME.  Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting).  It includes examples of many common CMS formats.  The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-smime-examples-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4134</errata-url>
        <doi>10.17487/RFC4134</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4135</doc-id>
        <title>Goals of Detecting Network Attachment in IPv6</title>
        <author>
            <name>JH. Choi</name>
        </author>
        <author>
            <name>G. Daley</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>dna</kw>
            <kw>detecting attachment links</kw>
            <kw>change detection</kw>
        </keywords>
        <abstract><p>When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity.  The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid.  During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed.  In this memo, this procedure is called Detecting Network Attachment (DNA).  DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dna-goals-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dna</wg_acronym>
        <doi>10.17487/RFC4135</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4136</doc-id>
        <title>OSPF Refresh and Flooding Reduction in Stable Topologies</title>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>link state advertisement</kw>
            <kw>lsa</kw>
            <kw>donotage</kw>
        </keywords>
        <abstract><p>This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.</p><p> Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-pillay-esnault-ospf-flooding-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC4136</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4137</doc-id>
        <title>State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator</title>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>N. Petroni</name>
        </author>
        <author>
            <name>Y. Ohba</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>eap stand-alone authenticator</kw>
            <kw>eap backend authenticator</kw>
            <kw>eap full authenticator</kw>
        </keywords>
        <abstract><p>This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.</p><p> The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.</p><p> The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-eap-statemachine-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>eap</wg_acronym>
        <doi>10.17487/RFC4137</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4138</doc-id>
        <title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>P. Sarolahti</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data.  This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts.  F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate.  After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious.  It then decides whether to send new segments or retransmit unacknowledged segments.  The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout.  The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-frto-02</draft>
        <updated-by>
            <doc-id>RFC5682</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC4138</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4139</doc-id>
        <title>Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)</title>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>J. Ash</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <date>
            <month>July</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>tdm</kw>
            <kw>otn</kw>
            <kw>control plane</kw>
            <kw>call</kw>
            <kw>connection</kw>
        </keywords>
        <abstract><p>The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).</p><p> This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ason-reqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4139</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4140</doc-id>
        <title>Hierarchical Mobile IPv6 Mobility Management (HMIPv6)</title>
        <author>
            <name>H. Soliman</name>
        </author>
        <author>
            <name>C. Castelluccia</name>
        </author>
        <author>
            <name>K. El Malki</name>
        </author>
        <author>
            <name>L. Bellier</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>neighbour discovery</kw>
            <kw>neighbor discovery</kw>
            <kw>mobility anchor point</kw>
            <kw>map</kw>
        </keywords>
        <abstract><p>This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling.  Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent.  The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-hmipv6-04</draft>
        <obsoleted-by>
            <doc-id>RFC5380</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4140</errata-url>
        <doi>10.17487/RFC4140</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4141</doc-id>
        <title>SMTP and MIME Extensions for Content Conversion</title>
        <author>
            <name>K. Toyoda</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>esmtp</kw>
            <kw>simple mail transfer protocol</kw>
            <kw>extended simple mail transfer protocol</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred.  Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white).  In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary.  This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fax-esmtp-conneg-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4141</errata-url>
        <doi>10.17487/RFC4141</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4142</doc-id>
        <title>Full-mode Fax Profile for Internet Mail (FFPIM)</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>facsimile</kw>
            <kw>full mode</kw>
            <kw>internet mail</kw>
        </keywords>
        <abstract><p>Classic facsimile document exchange represents both a set of technical specifications and a class of service.  Previous work has replicated some of that service class as a profile within Internet mail.  The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile.  These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. [PROPOSED STANDARD]</p></abstract>
        <draft>draft-ietf-fax-ffpim-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC4142</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4143</doc-id>
        <title>Facsimile Using Internet Mail (IFAX) Service of ENUM</title>
        <author>
            <name>K. Toyoda</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>naptr</kw>
            <kw>enum naming authority pointer</kw>
            <kw>facsimile using internet mail</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service.  IFax is "facsimile using Internet mail".  For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system.  This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fax-faxservice-enum-03</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4143</errata-url>
        <doi>10.17487/RFC4143</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4144</doc-id>
        <title>How to Gain Prominence and Influence in Standards Organizations</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-eastlake-prominence-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4144</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4145</doc-id>
        <title>TCP-Based Media Transport in the Session Description Protocol (SDP)</title>
        <author>
            <name>D. Yon</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>setup</kw>
            <kw>connection</kw>
            <kw>reestablishment</kw>
        </keywords>
        <abstract><p>This document describes how to express media transport over TCP using the Session Description Protocol (SDP).  It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-comedia-10</draft>
        <updated-by>
            <doc-id>RFC4572</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4145</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4146</doc-id>
        <title>Simple New Mail Notification</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>mail client</kw>
            <kw>nm_notifyuser</kw>
        </keywords>
        <abstract><p>This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.</p><p> In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-gellens-notify-mail-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4146</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4147</doc-id>
        <title>Proposed Changes to the Format of the IANA IPv6 Registry</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>address format</kw>
            <kw>address architecture</kw>
        </keywords>
        <abstract><p>This document proposes a revised format for the IANA IPv6 address registries.  Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format.  The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-huston-ip6-iana-registry-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4147</errata-url>
        <doi>10.17487/RFC4147</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4148</doc-id>
        <title>IP Performance Metrics (IPPM) Metrics Registry</title>
        <author>
            <name>E. Stephan</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>object identities</kw>
            <kw>iana-ippm-metrics-registry-mib</kw>
        </keywords>
        <abstract><p>This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.</p><p> This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.</p><p> IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ippm-metrics-registry-08</draft>
        <obsoleted-by>
            <doc-id>RFC6248</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>BCP0108</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC4148</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4149</doc-id>
        <title>Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms</title>
        <author>
            <name>C. Kalbfleisch</name>
        </author>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>sspm</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>sspm mib</kw>
        </keywords>
        <abstract><p>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 for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmonmib-sspm-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC4149</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4150</doc-id>
        <title>Transport Performance Metrics MIB</title>
        <author>
            <name>R. Dietz</name>
        </author>
        <author>
            <name>R. Cole</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>tpm</kw>
            <kw>tpm-mib</kw>
        </keywords>
        <abstract><p>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 selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions.  The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents.  The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmonmib-tpm-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC4150</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4151</doc-id>
        <title>The 'tag' URI Scheme</title>
        <author>
            <name>T. Kindberg</name>
        </author>
        <author>
            <name>S. Hawke</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>entity identifier</kw>
        </keywords>
        <abstract><p>This document describes the "tag" Uniform Resource Identifier (URI) scheme.  Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans.  They are distinct from most other URIs in that they have no authoritative resolution mechanism.  A tag may be used purely as an entity identifier.  Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kindberg-tag-uri-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4151</errata-url>
        <doi>10.17487/RFC4151</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4152</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code</title>
        <author>
            <name>K. Tesink</name>
        </author>
        <author>
            <name>R. Fox</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ansi</kw>
            <kw>ansi t1.213</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI.  The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213.  The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers.  The CLEI code identifies communications equipment by specifying product type and features.  There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-tesink-urn-clei-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4152</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4153</doc-id>
        <title>XML Voucher: Generic Voucher Language</title>
        <author>
            <name>K. Fujimura</name>
        </author>
        <author>
            <name>M. Terada</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>logical entity</kw>
        </keywords>
        <abstract><p>This document specifies rules for defining voucher properties in XML syntax.  A voucher is a logical entity that represents a right to claim goods or services.  A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-trade-voucher-lang-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC4153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4154</doc-id>
        <title>Voucher Trading System Application Programming Interface (VTS-API)</title>
        <author>
            <name>M. Terada</name>
        </author>
        <author>
            <name>K. Fujimura</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>wallet</kw>
            <kw>transfer</kw>
            <kw>redeem</kw>
        </keywords>
        <abstract><p>This document specifies the Voucher Trading System Application Programming Interface (VTS-API).  The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation.  The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates.  This process is often necessary in the course of payment and/or delivery transactions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-trade-voucher-vtsapi-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>trade</wg_acronym>
        <doi>10.17487/RFC4154</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4155</doc-id>
        <title>The application/mbox Media Type</title>
        <author>
            <name>E. Hall</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>mbox database</kw>
        </keywords>
        <abstract><p>This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048.  This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hall-mime-app-mbox-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4155</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4156</doc-id>
        <title>The wais URI Scheme</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
        </keywords>
        <abstract><p>This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.  This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-hoffman-wais-uri-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4156</errata-url>
        <doi>10.17487/RFC4156</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4157</doc-id>
        <title>The prospero URI Scheme</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
        </keywords>
        <abstract><p>This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.  This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-hoffman-prospero-uri-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4157</errata-url>
        <doi>10.17487/RFC4157</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4158</doc-id>
        <title>Internet X.509 Public Key Infrastructure: Certification Path Building</title>
        <author>
            <name>M. Cooper</name>
        </author>
        <author>
            <name>Y. Dzambasow</name>
        </author>
        <author>
            <name>P. Hesse</name>
        </author>
        <author>
            <name>S. Joseph</name>
        </author>
        <author>
            <name>R. Nicholas</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>certification path discovery</kw>
            <kw>path discovery</kw>
            <kw>certificate path building</kw>
            <kw>certificate path discovery</kw>
        </keywords>
        <abstract><p>This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications.  By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pkix-certpathbuild-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4159</doc-id>
        <title>Deprecation of "ip6.int"</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-huston-ip6-int-03</draft>
        <is-also>
            <doc-id>BCP0109</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4160</doc-id>
        <title>Internet Fax Gateway Requirements</title>
        <author>
            <name>K. Mimura</name>
        </author>
        <author>
            <name>K. Yokoyama</name>
        </author>
        <author>
            <name>T. Satoh</name>
        </author>
        <author>
            <name>C. Kanaide</name>
        </author>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>general switched telephone network facsimile service</kw>
            <kw>gstn fax</kw>
            <kw>internet fax service</kw>
            <kw>i-fax</kw>
            <kw>onramp gateway</kw>
        </keywords>
        <abstract><p>To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required.  This document provides recommendations for the functionality of Internet Fax Gateways.  In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax.  The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-fax-gateway-protocol-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC4160</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4161</doc-id>
        <title>Guidelines for Optional Services for Internet Fax Gateways</title>
        <author>
            <name>K. Mimura</name>
        </author>
        <author>
            <name>K. Yokoyama</name>
        </author>
        <author>
            <name>T. Satoh</name>
        </author>
        <author>
            <name>K. Watanabe</name>
        </author>
        <author>
            <name>C. Kanaide</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>general switched telephone network acsimile service</kw>
            <kw>gstn fax</kw>
            <kw>internet fax service</kw>
            <kw>i-fax</kw>
            <kw>offramp gateway</kw>
            <kw>onramp gateway</kw>
        </keywords>
        <abstract><p>To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.</p><p> This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-fax-gateway-options-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>fax</wg_acronym>
        <doi>10.17487/RFC4161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4162</doc-id>
        <title>Addition of SEED Cipher Suites to Transport Layer Security (TLS)</title>
        <author>
            <name>H.J. Lee</name>
        </author>
        <author>
            <name>J.H. Yoon</name>
        </author>
        <author>
            <name>J.I. Lee</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>encryption algorithm</kw>
            <kw>ciphersuite</kw>
        </keywords>
        <abstract><p>This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-lee-tls-seed-01</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4162</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4163</doc-id>
        <title>RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>internet protocol</kw>
            <kw>compression</kw>
            <kw>performance considerations</kw>
            <kw>intellectual property rights</kw>
            <kw>ipr</kw>
        </keywords>
        <abstract><p>This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group.  The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns.  The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rohc-tcp-requirements-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4163</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4164</doc-id>
        <title>RObust Header Compression (ROHC): Context Replication for ROHC Profiles</title>
        <author>
            <name>G. Pelletier</name>
        </author>
        <date>
            <month>August</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>context initialization</kw>
            <kw>short-lived</kw>
        </keywords>
        <abstract><p>This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095.  Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context.  Context replication is introduced to reduce the overhead of the context establishment procedure.  It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-context-replication-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4164</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4165</doc-id>
        <title>Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)</title>
        <author>
            <name>T. George</name>
        </author>
        <author>
            <name>B. Bidulock</name>
        </author>
        <author>
            <name>R. Dantu</name>
        </author>
        <author>
            <name>H. Schwarzbauer</name>
        </author>
        <author>
            <name>K. Morneault</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>ss7 over ip</kw>
            <kw>ss7/ip</kw>
            <kw>sigtran</kw>
            <kw>m2ua</kw>
        </keywords>
        <abstract><p>This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP).  This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol.  The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages.  The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sigtran-m2pa-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4165</errata-url>
        <doi>10.17487/RFC4165</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4166</doc-id>
        <title>Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement</title>
        <author>
            <name>L. Coene</name>
        </author>
        <author>
            <name>J. Pastor-Balbas</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document describes the applicability of the several protocols developed under the signalling transport framework.  A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sigtran-signalling-over-sctp-applic-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC4166</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4167</doc-id>
        <title>Graceful OSPF Restart Implementation Report</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted.  This document provides an implementation report for this extension to the base OSPF protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ospf-graceful-impl-report-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC4167</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4168</doc-id>
        <title>The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>transport mechanism</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities.  SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies.  As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-sctp-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4169</doc-id>
        <title>Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2</title>
        <author>
            <name>V. Torvinen</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>M. Naslund</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>tls</kw>
            <kw>transport layer security</kw>
            <kw>tunneled authentication</kw>
            <kw>man-in-the-middle attacks</kw>
        </keywords>
        <abstract><p>HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS.  This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication.  This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310).  This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-torvinen-http-digest-aka-v2-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4169</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4170</doc-id>
        <title>Tunneling Multiplexed Compressed RTP (TCRTP)</title>
        <author>
            <name>B. Thompson</name>
        </author>
        <author>
            <name>T. Koren</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking.  The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-avt-tcrtp-08</draft>
        <is-also>
            <doc-id>BCP0110</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4170</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4171</doc-id>
        <title>Internet Storage Name Service (iSNS)</title>
        <author>
            <name>J. Tseng</name>
        </author>
        <author>
            <name>K. Gibbons</name>
        </author>
        <author>
            <name>F. Travostino</name>
        </author>
        <author>
            <name>C. Du Laney</name>
        </author>
        <author>
            <name>J. Souza</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>123</page-count>
        <keywords>
            <kw>isns servers</kw>
            <kw>isns clients</kw>
            <kw>fibre channel devices</kw>
            <kw>ifcp</kw>
            <kw>intelligent storage discovery</kw>
        </keywords>
        <abstract><p>This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network.  iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network.  iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices.  iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-isns-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4171</errata-url>
        <doi>10.17487/RFC4171</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4172</doc-id>
        <title>iFCP - A Protocol for Internet Fibre Channel Storage Networking</title>
        <author>
            <name>C. Monia</name>
        </author>
        <author>
            <name>R. Mullendore</name>
        </author>
        <author>
            <name>F. Travostino</name>
        </author>
        <author>
            <name>W. Jeong</name>
        </author>
        <author>
            <name>M. Edwards</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>111</page-count>
        <keywords>
            <kw>gateway-to-gateway</kw>
            <kw>fibre channel fabric</kw>
            <kw>tcp</kw>
            <kw>transport control protocol</kw>
        </keywords>
        <abstract><p>This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network.  This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards.  The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-ifcp-14</draft>
        <updated-by>
            <doc-id>RFC6172</doc-id>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC4172</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4173</doc-id>
        <title>Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol</title>
        <author>
            <name>P. Sarkar</name>
        </author>
        <author>
            <name>D. Missimer</name>
        </author>
        <author>
            <name>C. Sapuntzakis</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>scsi</kw>
            <kw>tcp</kw>
            <kw>transport control protocol</kw>
            <kw>boot server</kw>
        </keywords>
        <abstract><p>Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP.  This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol.  The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-iscsi-boot-12</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4173</errata-url>
        <doi>10.17487/RFC4173</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4174</doc-id>
        <title>The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service</title>
        <author>
            <name>C. Monia</name>
        </author>
        <author>
            <name>J. Tseng</name>
        </author>
        <author>
            <name>K. Gibbons</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>isns</kw>
            <kw>internet storage name service</kw>
            <kw>iscsi</kw>
            <kw>internet scsi</kw>
            <kw>ifcp</kw>
            <kw>internet fibre channel</kw>
            <kw>storage devices</kw>
        </keywords>
        <abstract><p>This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4.  iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network.  iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-isnsoption-13</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4174</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4175</doc-id>
        <title>RTP Payload Format for Uncompressed Video</title>
        <author>
            <name>L. Gharai</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>packetization scheme</kw>
            <kw>real-time transport protocol</kw>
            <kw>real time transport protocol</kw>
            <kw>smpte</kw>
            <kw>society of motion picture television engineers</kw>
            <kw>video formats</kw>
        </keywords>
        <abstract><p>This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP.  It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M.  The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-uncomp-video-06</draft>
        <updated-by>
            <doc-id>RFC4421</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4175</errata-url>
        <doi>10.17487/RFC4175</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4176</doc-id>
        <title>Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management</title>
        <author>
            <name>Y. El Mghazli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>A. Gonguet</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs).  This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions.  The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l3vpn-mgt-fwk-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC4176</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4177</doc-id>
        <title>Architectural Approaches to Multi-homing for IPv6</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite.  The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing.  It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-multi6-architecture-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>multi6</wg_acronym>
        <doi>10.17487/RFC4177</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4178</doc-id>
        <title>The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <author>
            <name>W. Ingersoll</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>generic</kw>
            <kw>service</kw>
            <kw>application</kw>
            <kw>security</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.</p><p> This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-2478bis-05</draft>
        <obsoletes>
            <doc-id>RFC2478</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC4178</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4179</doc-id>
        <title>Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)</title>
        <author>
            <name>S. Kang</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>nca</kw>
            <kw>national computerization agency</kw>
            <kw>digital resources</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-sangug-uci-urn-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4179</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4180</doc-id>
        <title>Common Format and MIME Type for Comma-Separated Values (CSV) Files</title>
        <author>
            <name>Y. Shafranovich</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>text/csv</kw>
        </keywords>
        <abstract><p>This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shafranovich-mime-csv-05</draft>
        <updated-by>
            <doc-id>RFC7111</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4180</errata-url>
        <doi>10.17487/RFC4180</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4181</doc-id>
        <title>Guidelines for Authors and Reviewers of MIB Documents</title>
        <author>
            <name>C. Heard</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>standards-track specifications</kw>
            <kw>management information base</kw>
            <kw>review</kw>
        </keywords>
        <abstract><p>This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules.  Applicable portions may be used as a basis for reviews of other MIB documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ops-mib-review-guidelines-04</draft>
        <updated-by>
            <doc-id>RFC4841</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0111</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4181</errata-url>
        <doi>10.17487/RFC4181</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4182</doc-id>
        <title>Removing a Restriction on the use of MPLS Explicit NULL</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>ipv4 explicit null</kw>
        </keywords>
        <abstract><p>The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.</p><p> This document updates RFC 3032. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-explicit-null-02</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5462</doc-id>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4182</errata-url>
        <doi>10.17487/RFC4182</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4183</doc-id>
        <title>A Suggested Scheme for DNS Resolution of Networks and Gateways</title>
        <author>
            <name>E. Warnicke</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>domain name space</kw>
            <kw>ip address</kw>
            <kw>internet protocol address</kw>
            <kw>netmask</kw>
            <kw>first-hop router</kw>
            <kw>subnet</kw>
        </keywords>
        <abstract><p>This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network.  This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-warnicke-network-dns-resolution-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4183</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4184</doc-id>
        <title>RTP Payload Format for AC-3 Audio</title>
        <author>
            <name>B. Link</name>
        </author>
        <author>
            <name>T. Hager</name>
        </author>
        <author>
            <name>J. Flaks</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>audio compression</kw>
        </keywords>
        <abstract><p>This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard.  AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media.  The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-ac3-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4184</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4185</doc-id>
        <title>National and Local Characters for DNS Top Level Domain (TLD) Names</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>multilingual</kw>
            <kw>internationalized</kw>
            <kw>local translation</kw>
        </keywords>
        <abstract><p>In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script.  This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes.  It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties.  The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language.  It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-klensin-idn-tld-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4185</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4186</doc-id>
        <title>Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)</title>
        <author>
            <name>H. Haverinen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Salowey</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>3gpp</kw>
        </keywords>
        <abstract><p>This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM).  GSM is a second generation mobile network standard.  The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets.  The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-haverinen-pppext-eap-sim-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4186</errata-url>
        <doi>10.17487/RFC4186</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4187</doc-id>
        <title>Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>H. Haverinen</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>3gpp</kw>
            <kw>universal mobile telecommunications system</kw>
            <kw>umts</kw>
        </keywords>
        <abstract><p>This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.</p><p> EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-arkko-pppext-eap-aka-15</draft>
        <updated-by>
            <doc-id>RFC5448</doc-id>
            <doc-id>RFC9048</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4187</errata-url>
        <doi>10.17487/RFC4187</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4188</doc-id>
        <title>Definitions of Managed Objects for Bridges</title>
        <author>
            <name>K. Norseth</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Bell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>BRIDGE-MIB</kw>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.</p><p> The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.</p><p> This memo obsoletes RFC 1493. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bridge-bridgemib-smiv2-10</draft>
        <obsoletes>
            <doc-id>RFC1493</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4188</errata-url>
        <doi>10.17487/RFC4188</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4189</doc-id>
        <title>Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>K. Ono</name>
        </author>
        <author>
            <name>S. Tachimoto</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>user agent</kw>
            <kw>ua</kw>
            <kw>intermediaries</kw>
        </keywords>
        <abstract><p>A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message.  The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content.  This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security.  This document defines a set of requirements for a mechanism to achieve end-to-middle security.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-e2m-sec-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4189</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4190</doc-id>
        <title>Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony</title>
        <author>
            <name>K. Carlberg</name>
        </author>
        <author>
            <name>I. Brown</name>
        </author>
        <author>
            <name>C. Beard</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>disaster communications</kw>
            <kw>prioritized voip</kw>
        </keywords>
        <abstract><p>This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony.  We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models.  From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols.  Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document.  These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ieprep-framework-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <doi>10.17487/RFC4190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4191</doc-id>
        <title>Default Router Preferences and More-Specific Routes</title>
        <author>
            <name>R. Draves</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>router advertisement</kw>
        </keywords>
        <abstract><p>This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts.  This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links.  The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-router-selection-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4191</errata-url>
        <doi>10.17487/RFC4191</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4192</doc-id>
        <title>Procedures for Renumbering an IPv6 Network without a Flag Day</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>prefix</kw>
            <kw>internet protocol</kw>
            <kw>network interface</kw>
            <kw>make-before-break</kw>
            <kw>enterprise</kw>
            <kw>connecting routers</kw>
        </keywords>
        <abstract><p>This document describes a procedure that can be used to renumber a network from one prefix to another.  It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues.  It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-renumbering-procedure-05</draft>
        <updates>
            <doc-id>RFC2072</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4192</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4193</doc-id>
        <title>Unique Local IPv6 Unicast Addresses</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>local communication</kw>
        </keywords>
        <abstract><p>This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site.  These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-unique-local-addr-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4193</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4194</doc-id>
        <title>The S Hexdump Format</title>
        <author>
            <name>J. Strombergson</name>
        </author>
        <author>
            <name>L. Walleij</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>shf</kw>
            <kw>standard hex format</kw>
            <kw>secure hash standard</kw>
            <kw>shs</kw>
            <kw>sha-1</kw>
            <kw>nist fips 180-2</kw>
            <kw>binary data</kw>
            <kw>dump format</kw>
            <kw>hexadecimal</kw>
            <kw>intel hex format</kw>
            <kw>s-rec</kw>
            <kw>extensible markup language</kw>
            <kw>xml</kw>
        </keywords>
        <abstract><p>This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation.  SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-strombergson-shf-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4194</errata-url>
        <doi>10.17487/RFC4194</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4195</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum</title>
        <author>
            <name>W. Kameyama</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>digital broadcasting</kw>
            <kw>tv</kw>
            <kw>radio</kw>
            <kw>storage systems</kw>
            <kw>metadata</kw>
            <kw>schemas</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kameyama-tv-anytime-urn-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4195</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4196</doc-id>
        <title>The SEED Cipher Algorithm and Its Use with IPsec</title>
        <author>
            <name>H.J. Lee</name>
        </author>
        <author>
            <name>J.H. Yoon</name>
        </author>
        <author>
            <name>S.L. Lee</name>
        </author>
        <author>
            <name>J.I. Lee</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ipsec esp</kw>
            <kw>encryption algorithm</kw>
        </keywords>
        <abstract><p>This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-lee-ipsec-cipher-seed-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4196</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4197</doc-id>
        <title>Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks</title>
        <author>
            <name>M. Riegel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>digital signatures</kw>
            <kw>plesiochronous digital hierarchy</kw>
            <kw>sonet</kw>
            <kw>synchronous optical network</kw>
            <kw>sdh</kw>
            <kw>synchronous digital hierarchy</kw>
            <kw>pwe3</kw>
            <kw>pseudo wire emulation</kw>
        </keywords>
        <abstract><p>This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks.  It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3).  It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pwe3-tdm-requirements-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4197</errata-url>
        <doi>10.17487/RFC4197</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4198</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for Federated Content</title>
        <author>
            <name>D. Tessman</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>content resource</kw>
            <kw>content collections</kw>
        </keywords>
        <abstract><p>This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections.  A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dtessman-urn-namespace-federated-content-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4198</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4199</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4200</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4201</doc-id>
        <title>Link Bundling in MPLS Traffic Engineering (TE)</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>generalized multiprotocol label switching</kw>
            <kw>gmpls</kw>
            <kw>lsp</kw>
            <kw>label switched path</kw>
            <kw>interface identification tlvs</kw>
        </keywords>
        <abstract><p>For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of &lt;link identifier, label&gt; is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP).  Such cases are handled by using the link bundling construct, which is described in this document.  This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-bundle-06</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
            <doc-id>RFC3472</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4201</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4202</doc-id>
        <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
        <author>
            <name>K. Kompella</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS).  This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-routing-09</draft>
        <updated-by>
            <doc-id>RFC6001</doc-id>
            <doc-id>RFC6002</doc-id>
            <doc-id>RFC7074</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4202</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4203</doc-id>
        <title>OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
        <author>
            <name>K. Kompella</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-ospf-gmpls-extensions-12</draft>
        <updates>
            <doc-id>RFC3630</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6001</doc-id>
            <doc-id>RFC6002</doc-id>
            <doc-id>RFC7074</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4204</doc-id>
        <title>Link Management Protocol (LMP)</title>
        <author>
            <name>J. Lang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>gmpls</kw>
            <kw>sonet</kw>
            <kw>sdh</kw>
            <kw>discovery</kw>
            <kw>link verification</kw>
            <kw>fault managment</kw>
            <kw>control channel management</kw>
            <kw>link property correlation</kw>
            <kw>traffic engineering links</kw>
            <kw>trace monitoring</kw>
        </keywords>
        <abstract><p>For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link.  Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques.  This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links.  Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lmp-10</draft>
        <updated-by>
            <doc-id>RFC6898</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4204</errata-url>
        <doi>10.17487/RFC4204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4205</doc-id>
        <title>Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
        <author>
            <name>K. Kompella</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-isis-gmpls-extensions-19</draft>
        <obsoleted-by>
            <doc-id>RFC5307</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3784</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC4205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4206</doc-id>
        <title>Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>lsr</kw>
            <kw>label switching router</kw>
            <kw>te lsp</kw>
            <kw>fa</kw>
            <kw>forwarding adjacency</kw>
        </keywords>
        <abstract><p>To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).</p><p> This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]</p></abstract>
        <draft>draft-ietf-mpls-lsp-hierarchy-08</draft>
        <updated-by>
            <doc-id>RFC6001</doc-id>
            <doc-id>RFC6107</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4206</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4207</doc-id>
        <title>Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages</title>
        <author>
            <name>J. Lang</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>gmpls</kw>
            <kw>discovery</kw>
            <kw>link verification</kw>
            <kw>fault management</kw>
            <kw>control channel management</kw>
            <kw>link property correlation</kw>
            <kw>traffic engineering links</kw>
            <kw>trace monitoring</kw>
        </keywords>
        <abstract><p>This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lmp-test-sonet-sdh-04</draft>
        <updated-by>
            <doc-id>RFC6898</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4207</errata-url>
        <doi>10.17487/RFC4207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4208</doc-id>
        <title>Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model</title>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>H. Ishimatsu</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>lsp</kw>
            <kw>label switched paths</kw>
            <kw>routing protocol</kw>
            <kw>signaling protocol</kw>
        </keywords>
        <abstract><p>Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies.  These protocols can be used to support a number of deployment scenarios.  This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-overlay-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4209</doc-id>
        <title>Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems</title>
        <author>
            <name>A. Fredette</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Lang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>te</kw>
            <kw>traffic engineering</kw>
            <kw>peer nodes</kw>
            <kw>ols</kw>
            <kw>optical link interface requirements</kw>
        </keywords>
        <abstract><p>The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links.  In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing.  This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS).  These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lmp-wdm-03</draft>
        <updated-by>
            <doc-id>RFC6898</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4209</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4210</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)</title>
        <author>
            <name>C. Adams</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>T. Kause</name>
        </author>
        <author>
            <name>T. Mononen</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>PKICMP security</kw>
            <kw>cryptographic authentication</kw>
            <kw>pkix</kw>
            <kw>pki</kw>
            <kw>X.509v3</kw>
            <kw>certificate creation</kw>
            <kw>certificate management</kw>
            <kw>ca</kw>
            <kw>certification authority</kw>
        </keywords>
        <abstract><p>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP).  Protocol messages are defined for X.509v3 certificate creation and management.  CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc2510bis-09</draft>
        <obsoletes>
            <doc-id>RFC2510</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9810</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6712</doc-id>
            <doc-id>RFC9480</doc-id>
            <doc-id>RFC9481</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4210</errata-url>
        <doi>10.17487/RFC4210</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4211</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>September</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>X.509-CRMF</kw>
            <kw>certification authority</kw>
            <kw>ca</kw>
            <kw>registration authority</kw>
            <kw>ra</kw>
            <kw>pkix</kw>
            <kw>pki</kw>
            <kw>certificate production</kw>
            <kw>crmf</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>authenticaion</kw>
        </keywords>
        <abstract><p>This document describes the Certificate Request Message Format (CRMF) syntax and semantics.  This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production.  The request will typically include a public key and the associated registration information.  This document does not define a certificate request protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc2511bis-08</draft>
        <obsoletes>
            <doc-id>RFC2511</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9045</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4211</errata-url>
        <doi>10.17487/RFC4211</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4212</doc-id>
        <title>Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols</title>
        <author>
            <name>M. Blinov</name>
        </author>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>X.509v3</kw>
            <kw>public-key certificates</kw>
            <kw>crmf</kw>
            <kw>certificate request message format</kw>
            <kw>pkix certificate management protocol</kw>
            <kw>pkix-cmp</kw>
            <kw>certificate management messages over cms</kw>
            <kw>cmc</kw>
        </keywords>
        <abstract><p>The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols.  These protocols are primarily focused on X.509v3 public-key certificates.  However, it is sometimes desirable to manage certificates in alternative formats as well.  This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols.  It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-adams-cmpaltcert-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4212</errata-url>
        <doi>10.17487/RFC4212</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4213</doc-id>
        <title>Basic Transition Mechanisms for IPv6 Hosts and Routers</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>R. Gilligan</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>TRANS-IPV6</kw>
            <kw>ipv4</kw>
            <kw>dual sack</kw>
            <kw>configured tunneling</kw>
        </keywords>
        <abstract><p>This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.</p><p> This document obsoletes RFC 2893. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-v6ops-mech-v2-07</draft>
        <obsoletes>
            <doc-id>RFC2893</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4213</errata-url>
        <doi>10.17487/RFC4213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4214</doc-id>
        <title>Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)</title>
        <author>
            <name>F. Templin</name>
        </author>
        <author>
            <name>T. Gleeson</name>
        </author>
        <author>
            <name>M. Talwar</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ISATAP</kw>
            <kw>ipv4</kw>
            <kw>link layer</kw>
            <kw>nbma</kw>
            <kw>non-broadcast multiple access</kw>
        </keywords>
        <abstract><p>The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks.  ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers.  ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ngtrans-isatap-22</draft>
        <obsoleted-by>
            <doc-id>RFC5214</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4214</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4215</doc-id>
        <title>Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks</title>
        <author>
            <name>J. Wiljakka</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>gprs</kw>
            <kw>general packet radio service</kw>
            <kw>global system for mobile communications</kw>
            <kw>gsm</kw>
            <kw>universal mobile telecommunications system</kw>
            <kw>umts</kw>
            <kw>wideband code division multiple access</kw>
            <kw>wcdma</kw>
        </keywords>
        <abstract><p>This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.</p><p> The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-3gpp-analysis-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4215</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4216</doc-id>
        <title>MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements</title>
        <author>
            <name>R. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J.-P. Vasseur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>inter-as</kw>
            <kw>mpls-te</kw>
        </keywords>
        <abstract><p>This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE).  Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tewg-interas-mpls-te-req-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>subip</area>
        <wg_acronym>tewg</wg_acronym>
        <doi>10.17487/RFC4216</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4217</doc-id>
        <title>Securing FTP with TLS</title>
        <author>
            <name>P. Ford-Hutchinson</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>file transfer protocol</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".</p><p> This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-murray-auth-ftp-ssl-16</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4217</errata-url>
        <doi>10.17487/RFC4217</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4218</doc-id>
        <title>Threats Relating to IPv6 Multihoming Solutions</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>security threats</kw>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.</p><p> The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-multi6-multihoming-threats-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>multi6</wg_acronym>
        <doi>10.17487/RFC4218</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4219</doc-id>
        <title>Things Multihoming in IPv6 (MULTI6) Developers Should Think About</title>
        <author>
            <name>E. Lear</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>security threats</kw>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6.  The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-multi6-things-to-think-about-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>multi6</wg_acronym>
        <doi>10.17487/RFC4219</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4220</doc-id>
        <title>Traffic Engineering Link Management Information Base</title>
        <author>
            <name>M. Dubuc</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>J. Lang</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>network management protocols</kw>
            <kw>te</kw>
            <kw>te-link-std-mib</kw>
        </keywords>
        <abstract><p>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 modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-telink-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4220</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4221</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Management Overview</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>C. Srinivasan</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>management architecture</kw>
            <kw>network management</kw>
        </keywords>
        <abstract><p>A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.</p><p> This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-mgmt-overview-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4221</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4222</doc-id>
        <title>Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance</title>
        <author>
            <name>G. Choudhury</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>lsa</kw>
            <kw>link state advertisement</kw>
        </keywords>
        <abstract><p>This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol.  The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ospf-scalability-09</draft>
        <updated-by>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0112</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC4222</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4223</doc-id>
        <title>Reclassification of RFC 1863 to Historic</title>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>BGP-IDRP</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>inter-domain</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status.  This memo also obsoletes RFC 1863.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-rfc1863-historic-00</draft>
        <obsoletes>
            <doc-id>RFC1863</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC4223</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4224</doc-id>
        <title>RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets</title>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>K. Sandlund</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles).  One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering.  This document discusses aspects of using ROHC over channels that can reorder packets.  It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rohc-over-reordering-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4224</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4225</doc-id>
        <title>Mobile IP Version 6 Route Optimization Security Design Background</title>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>T. Aura</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>mipv6</kw>
            <kw>mip</kw>
        </keywords>
        <abstract><p>This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.</p><p> The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-ro-sec-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC4225</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4226</doc-id>
        <title>HOTP: An HMAC-Based One-Time Password Algorithm</title>
        <author>
            <name>D. M'Raihi</name>
        </author>
        <author>
            <name>M. Bellare</name>
        </author>
        <author>
            <name>F. Hoornaert</name>
        </author>
        <author>
            <name>D. Naccache</name>
        </author>
        <author>
            <name>O. Ranen</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>hashed message authentication code</kw>
            <kw>security analysis</kw>
            <kw>oath</kw>
            <kw>open authentication</kw>
            <kw>authentication</kw>
            <kw>OATH</kw>
        </keywords>
        <abstract><p>This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.</p><p> This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mraihi-oath-hmac-otp-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4226</errata-url>
        <doi>10.17487/RFC4226</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4227</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>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>remote procedure calling</kw>
            <kw>rpc</kw>
            <kw>asynchronous event notification</kw>
            <kw>unacknowledged messages</kw>
            <kw>binding</kw>
        </keywords>
        <abstract><p>This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.</p><p> The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mrose-rfc3288bis-02</draft>
        <obsoletes>
            <doc-id>RFC3288</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4227</errata-url>
        <doi>10.17487/RFC4227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4228</doc-id>
        <title>Requirements for an IETF Draft Submission Toolset</title>
        <author>
            <name>A. Rousskov</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>automation</kw>
            <kw>tool</kw>
        </keywords>
        <abstract><p>This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tools-draft-submission-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4229</doc-id>
        <title>HTTP Header Field Registrations</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>hyper text transfer protocol</kw>
        </keywords>
        <abstract><p>This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-nottingham-hdrreg-http-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4229</errata-url>
        <doi>10.17487/RFC4229</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4230</doc-id>
        <title>RSVP Security Properties</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>R. Graveman</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>This document summarizes the security properties of RSVP.  The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-rsvp-sec-properties-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4230</errata-url>
        <doi>10.17487/RFC4230</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4231</doc-id>
        <title>Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512</title>
        <author>
            <name>M. Nystrom</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>message authentication codes</kw>
            <kw>message authentication schemes</kw>
        </keywords>
        <abstract><p>This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes.  It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols.  The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-nystrom-smime-hmac-sha-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4231</errata-url>
        <doi>10.17487/RFC4231</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4232</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4233</doc-id>
        <title>Integrated Services Digital Network (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>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>stream control transmission protocol</kw>
            <kw>sctp</kw>
            <kw>signaling gateway</kw>
            <kw>sg</kw>
            <kw>media gateway controller</kw>
            <kw>mgc</kw>
            <kw>signaling</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>interface</kw>
        </keywords>
        <abstract><p>This document defines a protocol for backhauling of Integrated Services Digital Network (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). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.</p><p> This document obsoletes RFC 3057. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sigtran-rfc3057bis-02</draft>
        <obsoletes>
            <doc-id>RFC3057</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5133</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC4233</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4234</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>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ABNF</kw>
            <kw>backus-naur form</kw>
            <kw>augmented backus-naur form</kw>
            <kw>rule definitions</kw>
            <kw>encoding</kw>
            <kw>core lexical analyzer</kw>
            <kw>electronic mail</kw>
        </keywords>
        <abstract><p>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity, with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-crocker-abnf-rfc2234bis-00</draft>
        <obsoletes>
            <doc-id>RFC2234</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5234</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4234</errata-url>
        <doi>10.17487/RFC4234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4235</doc-id>
        <title>An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>R. Mahy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>sip events</kw>
            <kw>dialog package</kw>
        </keywords>
        <abstract><p>This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package.  The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-dialog-package-06</draft>
        <updated-by>
            <doc-id>RFC7463</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4235</errata-url>
        <doi>10.17487/RFC4235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4236</doc-id>
        <title>HTTP Adaptation with Open Pluggable Edge Services (OPES)</title>
        <author>
            <name>A. Rousskov</name>
        </author>
        <author>
            <name>M. Stecher</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>callout protocol</kw>
            <kw>ocp</kw>
            <kw>opes tracing</kw>
            <kw>opes bypass</kw>
        </keywords>
        <abstract><p>Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol.  This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation.  Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opes-http-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC4236</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4237</doc-id>
        <title>Voice Messaging Directory Service</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>vpim</kw>
            <kw>voice profile for internet mail</kw>
        </keywords>
        <abstract><p>This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.</p><p> The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vpim-vpimdir-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4237</errata-url>
        <doi>10.17487/RFC4237</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4238</doc-id>
        <title>Voice Message Routing Service</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>vpim</kw>
            <kw>telephone number addressing</kw>
            <kw>voice profile and internet mail</kw>
            <kw>vpim directory</kw>
        </keywords>
        <abstract><p>Voice messaging is traditionally addressed using telephone number addressing.  This document describes two techniques for routing voice messages based on a telephone number.  The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient.  However, this service will take time to become widely deployed in the near term.  This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vpim-routing-10</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4238</errata-url>
        <doi>10.17487/RFC4238</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4239</doc-id>
        <title>Internet Voice Messaging (IVM)</title>
        <author>
            <name>S. McRae</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>voicemail</kw>
            <kw>vpim</kw>
            <kw>voice profile for internet mail</kw>
        </keywords>
        <abstract><p>This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.</p><p> The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vpim-ivm-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vpim</wg_acronym>
        <doi>10.17487/RFC4239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4240</doc-id>
        <title>Basic Network Media Services with SIP</title>
        <author>
            <name>E. Burger</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Van Dyke</name>
        </author>
        <author>
            <name>A. Spitzer</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>session initiation protocol</kw>
            <kw>network media services</kw>
            <kw>media servers</kw>
            <kw>application servers</kw>
        </keywords>
        <abstract><p>In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.</p><p> This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-burger-sipping-netann-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4240</errata-url>
        <doi>10.17487/RFC4240</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4241</doc-id>
        <title>A Model of IPv6/IPv4 Dual Stack Internet Access Service</title>
        <author>
            <name>Y. Shirasaki</name>
        </author>
        <author>
            <name>S. Miyakawa</name>
        </author>
        <author>
            <name>T. Yamasaki</name>
        </author>
        <author>
            <name>A. Takenouchi</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>user network specification</kw>
            <kw>ntt communications</kw>
            <kw>adsl</kw>
            <kw>cpe</kw>
            <kw>customer preises equipment</kw>
        </keywords>
        <abstract><p>This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users.  In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically.  The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shirasaki-dualstack-service-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4241</errata-url>
        <doi>10.17487/RFC4241</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4242</doc-id>
        <title>Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6.  It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-lifetime-03</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4242</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4243</doc-id>
        <title>Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option</title>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>R. Johnson</name>
        </author>
        <author>
            <name>T. Palaniappan</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option.  The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-vendor-suboption-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4243</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4244</doc-id>
        <title>An Extension to the Session Initiation Protocol (SIP) for Request History Information</title>
        <author>
            <name>M. Barnes</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>history-info</kw>
            <kw>retarget</kw>
            <kw>enhanced services</kw>
            <kw>voicemail</kw>
            <kw>automatic call distribution</kw>
        </keywords>
        <abstract><p>This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request.  This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user.  This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-history-info-06</draft>
        <obsoleted-by>
            <doc-id>RFC7044</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4244</errata-url>
        <doi>10.17487/RFC4244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4245</doc-id>
        <title>High-Level Requirements for Tightly Coupled SIP Conferencing</title>
        <author>
            <name>O. Levin</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>session initiation protocol</kw>
        </keywords>
        <abstract><p>This document examines a wide range of conferencing requirements for tightly coupled SIP conferences.  Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed.  Together, these documents will provide a guide for building interoperable SIP conferencing applications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-conferencing-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4246</doc-id>
        <title>International Standard Audiovisual Number (ISAN) URN Definition</title>
        <author>
            <name>M. Dolan</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>numbering system</kw>
            <kw>international identification</kw>
            <kw>audiovisual</kw>
            <kw>uniform resource identifier</kw>
        </keywords>
        <abstract><p>The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works.  This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dolan-urn-isan-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4247</doc-id>
        <title>Requirements for Header Compression over MPLS</title>
        <author>
            <name>J. Ash</name>
        </author>
        <author>
            <name>B. Goode</name>
        </author>
        <author>
            <name>J. Hand</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>voip</kw>
            <kw>voice over ip</kw>
        </keywords>
        <abstract><p>Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.  When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.  For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example.  Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC).  We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router.  This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router.  In this document, we give a problem statement, goals and requirements, and an example scenario.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-avt-hc-mpls-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4247</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4248</doc-id>
        <title>The telnet URI Scheme</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>October</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>url</kw>
            <kw>uniform resource locators</kw>
        </keywords>
        <abstract><p>This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hoffman-telnet-uri-05</draft>
        <obsoletes>
            <doc-id>RFC1738</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4248</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4249</doc-id>
        <title>Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components</title>
        <author>
            <name>B. Lilly</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>header field generator</kw>
            <kw>header field parser</kw>
        </keywords>
        <abstract><p>Implementation of generators and parsers of header fields requires certain information about those fields.  Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields.  Lacking such explicit information, implementers may guess, and interoperability may suffer.  This memo identifies information useful to implementers of header field generators and parsers.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-lilly-field-specification-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4249</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4250</doc-id>
        <title>The Secure Shell (SSH) Protocol Assigned Numbers</title>
        <author>
            <name>S. Lehtinen</name>
        </author>
        <author>
            <name>C. Lonvick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>remote login</kw>
        </keywords>
        <abstract><p>This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol.  It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-assignednumbers-12</draft>
        <updated-by>
            <doc-id>RFC8268</doc-id>
            <doc-id>RFC9142</doc-id>
            <doc-id>RFC9519</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <doi>10.17487/RFC4250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4251</doc-id>
        <title>The Secure Shell (SSH) Protocol Architecture</title>
        <author>
            <name>T. Ylonen</name>
        </author>
        <author>
            <name>C. Lonvick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>remote login</kw>
            <kw>ssh algorithm</kw>
        </keywords>
        <abstract><p>The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network.  This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents.  It also discusses the SSH algorithm naming system that allows local extensions.  The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy.  The User Authentication Protocol authenticates the client to the server.  The Connection Protocol multiplexes the encrypted tunnel into several logical channels.  Details of these protocols are described in separate documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-architecture-22</draft>
        <updated-by>
            <doc-id>RFC8308</doc-id>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <doi>10.17487/RFC4251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4252</doc-id>
        <title>The Secure Shell (SSH) Authentication Protocol</title>
        <author>
            <name>T. Ylonen</name>
        </author>
        <author>
            <name>C. Lonvick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>remote login</kw>
            <kw>public key</kw>
            <kw>password</kw>
            <kw>host-based client authentication</kw>
        </keywords>
        <abstract><p>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.  This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods.  Additional authentication methods are described in separate documents.  The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-userauth-27</draft>
        <updated-by>
            <doc-id>RFC8308</doc-id>
            <doc-id>RFC8332</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4252</errata-url>
        <doi>10.17487/RFC4252</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4253</doc-id>
        <title>The Secure Shell (SSH) Transport Layer Protocol</title>
        <author>
            <name>T. Ylonen</name>
        </author>
        <author>
            <name>C. Lonvick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>remote login</kw>
            <kw>encryption</kw>
            <kw>server authentication</kw>
            <kw>integrity protection</kw>
            <kw>diffie-hellman key exchange</kw>
            <kw>diffie hellman</kw>
        </keywords>
        <abstract><p>The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</p><p> This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.</p><p> Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.</p><p> This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-transport-24</draft>
        <updated-by>
            <doc-id>RFC6668</doc-id>
            <doc-id>RFC8268</doc-id>
            <doc-id>RFC8308</doc-id>
            <doc-id>RFC8332</doc-id>
            <doc-id>RFC8709</doc-id>
            <doc-id>RFC8758</doc-id>
            <doc-id>RFC9142</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4253</errata-url>
        <doi>10.17487/RFC4253</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4254</doc-id>
        <title>The Secure Shell (SSH) Connection Protocol</title>
        <author>
            <name>T. Ylonen</name>
        </author>
        <author>
            <name>C. Lonvick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>remote login</kw>
            <kw>interactive login</kw>
            <kw>remote execution</kw>
            <kw>encrypted tunnel</kw>
        </keywords>
        <abstract><p>Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</p><p> This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.</p><p> The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-connect-25</draft>
        <updated-by>
            <doc-id>RFC8308</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4254</errata-url>
        <doi>10.17487/RFC4254</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4255</doc-id>
        <title>Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints</title>
        <author>
            <name>J. Schlyter</name>
        </author>
        <author>
            <name>W. Griffin</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>dnssec</kw>
            <kw>domain name system security</kw>
        </keywords>
        <abstract><p>This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC).  The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-dns-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4255</errata-url>
        <doi>10.17487/RFC4255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4256</doc-id>
        <title>Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)</title>
        <author>
            <name>F. Cusack</name>
        </author>
        <author>
            <name>M. Forssen</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>remote login</kw>
            <kw>alphanumeric input</kw>
        </keywords>
        <abstract><p>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.  This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device).  The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-auth-kbdinteract-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4256</errata-url>
        <doi>10.17487/RFC4256</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4257</doc-id>
        <title>Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks</title>
        <author>
            <name>G. Bernstein</name>
        </author>
        <author>
            <name>E. Mannie</name>
        </author>
        <author>
            <name>V. Sharma</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>optical switching</kw>
            <kw>sdh</kw>
            <kw>sonet</kw>
        </keywords>
        <abstract><p>Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching.  One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks.  This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks.  SDH/SONET networks make good examples of this process for a variety of reasons.  This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits.  New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-sdhsonet-control-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4258</doc-id>
        <title>Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)</title>
        <author>
            <name>D. Brungard</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>control domain</kw>
            <kw>hierarchy</kw>
            <kw>multi-level</kw>
            <kw>multi-layer</kw>
            <kw>inter-domain</kw>
            <kw>intra-domain</kw>
            <kw>e-nni</kw>
            <kw>i-nni</kw>
            <kw>uni</kw>
        </keywords>
        <abstract><p>The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).</p><p> This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ason-routing-reqts-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4258</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4259</doc-id>
        <title>A Framework for Transmission of IP Datagrams over MPEG-2 Networks</title>
        <author>
            <name>M.-J. Montpetit</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>H. Clausen</name>
        </author>
        <author>
            <name>B. Collini-Nocker</name>
        </author>
        <author>
            <name>H. Linder</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>digital television</kw>
            <kw>dvb</kw>
            <kw>digital video broadcast</kw>
            <kw>atsc</kw>
            <kw>advanced television systems committee</kw>
        </keywords>
        <abstract><p>This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.</p><p> The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipdvb-arch-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipdvb</wg_acronym>
        <doi>10.17487/RFC4259</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4260</doc-id>
        <title>Mobile IPv6 Fast Handovers for 802.11 Networks</title>
        <author>
            <name>P. McCann</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>link layer</kw>
        </keywords>
        <abstract><p>This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-80211fh-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC4260</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4261</doc-id>
        <title>Common Open Policy Service (COPS) Over Transport Layer Security (TLS)</title>
        <author>
            <name>J. Walker</name>
        </author>
        <author>
            <name>A. Kulkarni</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>client-accept message</kw>
        </keywords>
        <abstract><p>This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.</p><p> This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rap-cops-tls-11</draft>
        <updates>
            <doc-id>RFC2748</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rap</wg_acronym>
        <doi>10.17487/RFC4261</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4262</doc-id>
        <title>X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>cryptographic capabilities</kw>
        </keywords>
        <abstract><p>This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280.  This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-certcapa-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC4262</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4263</doc-id>
        <title>Media Subtype Registration for Media Type text/troff</title>
        <author>
            <name>B. Lilly</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-lilly-text-troff-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4263</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4264</doc-id>
        <title>BGP Wedgies</title>
        <author>
            <name>T. Griffin</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner.  In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable.  Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner.  These stable, but unintended, BGP states are termed here "BGP Wedgies".  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-grow-bgp-wedgies-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC4264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4265</doc-id>
        <title>Definition of Textual Conventions for Virtual Private Network (VPN) Management</title>
        <author>
            <name>B. Schliesser</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>tc</kw>
        </keywords>
        <abstract><p>This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-tc-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC4265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4266</doc-id>
        <title>The gopher URI Scheme</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>url</kw>
        </keywords>
        <abstract><p>This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hoffman-gopher-uri-03</draft>
        <obsoletes>
            <doc-id>RFC1738</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4267</doc-id>
        <title>The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml</title>
        <author>
            <name>M. Froumentin</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>voice browser</kw>
            <kw>voice extensible markup language</kw>
            <kw>voicexml</kw>
            <kw>speech synthesis markup language</kw>
            <kw>ssml</kw>
            <kw>speech recognition grammar specification</kw>
            <kw>srgs</kw>
            <kw>call control xml</kw>
            <kw>ccxml</kw>
            <kw>pronunciation lexicon specification</kw>
            <kw>pls</kw>
        </keywords>
        <abstract><p>This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-froumentin-voice-mediatypes-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4268</doc-id>
        <title>Entity State MIB</title>
        <author>
            <name>S. Chisholm</name>
        </author>
        <author>
            <name>D. Perkins</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>snmp</kw>
            <kw>entity-state-tc-mib</kw>
        </keywords>
        <abstract><p>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 extensions to the Entity MIB to provide information about the state of physical entities.</p><p> In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-entmib-state-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>entmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4268</errata-url>
        <doi>10.17487/RFC4268</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4269</doc-id>
        <title>The SEED Encryption Algorithm</title>
        <author>
            <name>H.J. Lee</name>
        </author>
        <author>
            <name>S.J. Lee</name>
        </author>
        <author>
            <name>J.H. Yoon</name>
        </author>
        <author>
            <name>D.H. Cheon</name>
        </author>
        <author>
            <name>J.I. Lee</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>encryption algorithm</kw>
            <kw>seed cbc</kw>
            <kw>seed oid</kw>
        </keywords>
        <abstract><p>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 encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).</p><p> This document obsoletes RFC 4009. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-lee-rfc4009bis-02</draft>
        <obsoletes>
            <doc-id>RFC4009</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4270</doc-id>
        <title>Attacks on Cryptographic Hashes in Internet Protocols</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>B. Schneier</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>collision attacks</kw>
            <kw>hash algorithms</kw>
            <kw>ip</kw>
            <kw>digital certificates</kw>
        </keywords>
        <abstract><p>Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how.  This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hoffman-hash-attacks-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4270</errata-url>
        <doi>10.17487/RFC4270</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4271</doc-id>
        <title>A Border Gateway Protocol 4 (BGP-4)</title>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Li</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hares</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>104</page-count>
        <keywords>
            <kw>BGP-4</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</p><p> The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</p><p> BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</p><p> This document obsoletes RFC 1771. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-bgp4-26</draft>
        <obsoletes>
            <doc-id>RFC1771</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4724</doc-id>
            <doc-id>RFC6286</doc-id>
            <doc-id>RFC6608</doc-id>
            <doc-id>RFC6793</doc-id>
            <doc-id>RFC7606</doc-id>
            <doc-id>RFC7607</doc-id>
            <doc-id>RFC7705</doc-id>
            <doc-id>RFC8212</doc-id>
            <doc-id>RFC8654</doc-id>
            <doc-id>RFC9072</doc-id>
            <doc-id>RFC9687</doc-id>
            <doc-id>RFC9774</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4271</errata-url>
        <doi>10.17487/RFC4271</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4272</doc-id>
        <title>BGP Security Vulnerabilities Analysis</title>
        <author>
            <name>S. Murphy</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>attacks</kw>
            <kw>risks</kw>
            <kw>insider threat</kw>
        </keywords>
        <abstract><p>Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.</p><p> This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-bgp-vuln-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC4272</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4273</doc-id>
        <title>Definitions of Managed Objects for BGP-4</title>
        <author>
            <name>J. Haas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hares</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>BGP-4-MIB</kw>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>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.</p><p> The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.</p><p> This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions.</p><p> This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-bgp4-mib-15</draft>
        <obsoletes>
            <doc-id>RFC1269</doc-id>
            <doc-id>RFC1657</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4273</errata-url>
        <doi>10.17487/RFC4273</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4274</doc-id>
        <title>BGP-4 Protocol Analysis</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).</p><p> This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-bgp-analysis-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4274</errata-url>
        <doi>10.17487/RFC4274</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4275</doc-id>
        <title>BGP-4 MIB Implementation Survey</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>D. Hares</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-bgp-mibagent-survey-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4275</errata-url>
        <doi>10.17487/RFC4275</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4276</doc-id>
        <title>BGP-4 Implementation Report</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>97</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).</p><p> The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-bgp-implementation-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC4276</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4277</doc-id>
        <title>Experience with the BGP-4 Protocol</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).</p><p> This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-bgp4-experience-protocol-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4277</errata-url>
        <doi>10.17487/RFC4277</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4278</doc-id>
        <title>Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization.  RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF.  This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option".  RFC 2385 will remain at the Proposed Standard level.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iesg-tcpmd5app-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC4278</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4279</doc-id>
        <title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
        <author>
            <name>P. Eronen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>psk</kw>
            <kw>psks</kw>
            <kw>symmetric keys</kw>
            <kw>diffie-hellman</kw>
        </keywords>
        <abstract><p>This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs).  These pre-shared keys are symmetric keys, shared in advance among the communicating parties.  The first set of ciphersuites uses only symmetric key operations for authentication.  The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-psk-09</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC4279</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4280</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers</title>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>P. Yegani</name>
        </author>
        <author>
            <name>L. Madour</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>bcmcs</kw>
            <kw>3g</kw>
            <kw>third generation</kw>
            <kw>cellular telephone</kw>
            <kw>mobile node</kw>
            <kw>mn</kw>
        </keywords>
        <abstract><p>This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network.  BCMCS is being developed for Third generation (3G) cellular telephone networks.  Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service.  Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller.  This document defines the related options and option codes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-bcmc-options-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4280</errata-url>
        <doi>10.17487/RFC4280</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4281</doc-id>
        <title>The Codecs Parameter for "Bucket" Media Types</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>P. Frojdh</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>codec</kw>
            <kw>container</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>3gpp</kw>
            <kw>3gpp2</kw>
        </keywords>
        <abstract><p>Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.</p><p> This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.</p><p> By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gellens-mime-bucket-04</draft>
        <obsoleted-by>
            <doc-id>RFC6381</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4281</errata-url>
        <doi>10.17487/RFC4281</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4282</doc-id>
        <title>The Network Access Identifier</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>M. Beadles</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>NAI</kw>
            <kw>nai</kw>
            <kw>roaming</kw>
            <kw>tunneling</kw>
        </keywords>
        <abstract><p>In order to provide roaming services, it is necessary to have a standardized method for identifying users.  This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one.  Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support.  This document is a revised version of RFC 2486, which originally defined NAIs.  Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-rfc2486bis-06</draft>
        <obsoletes>
            <doc-id>RFC2486</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7542</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4282</errata-url>
        <doi>10.17487/RFC4282</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4283</doc-id>
        <title>Mobile Node Identifier Option for Mobile IPv6 (MIPv6)</title>
        <author>
            <name>A. Patel</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>M. Khalil</name>
        </author>
        <author>
            <name>H. Akhtar</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mobility header</kw>
            <kw>mobile nodes</kw>
            <kw>correspondent nodes</kw>
            <kw>home agents</kw>
        </keywords>
        <abstract><p>Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings.  Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address.  Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN).  This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-mn-ident-option-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4283</errata-url>
        <doi>10.17487/RFC4283</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4284</doc-id>
        <title>Identity Selection Hints for the Extensible Authentication Protocol (EAP)</title>
        <author>
            <name>F. Adrangi</name>
        </author>
        <author>
            <name>V. Lortz</name>
        </author>
        <author>
            <name>F. Bari</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>nai</kw>
            <kw>network access identifier</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.</p><p> The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-adrangi-eap-network-discovery-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4284</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4285</doc-id>
        <title>Authentication Protocol for Mobile IPv6</title>
        <author>
            <name>A. Patel</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>M. Khalil</name>
        </author>
        <author>
            <name>H. Akhtar</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ip security</kw>
            <kw>ipsec</kw>
            <kw>mip6</kw>
            <kw>mobile node</kw>
            <kw>home agent</kw>
        </keywords>
        <abstract><p>IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).  MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent.  This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents.  The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-auth-protocol-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4285</errata-url>
        <doi>10.17487/RFC4285</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4286</doc-id>
        <title>Multicast Router Discovery</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>J. Martin</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>igmp</kw>
            <kw>internet group management protocol</kw>
            <kw>mld</kw>
            <kw>multicast listener discovery</kw>
            <kw>mrd</kw>
        </keywords>
        <abstract><p>The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.</p><p> This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-magma-mrdisc-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4286</errata-url>
        <doi>10.17487/RFC4286</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4287</doc-id>
        <title>The Atom Syndication Format</title>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Sayre</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>xml-basd web content</kw>
            <kw>metadata</kw>
        </keywords>
        <abstract><p>This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-atompub-format-11</draft>
        <updated-by>
            <doc-id>RFC5988</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>atompub</wg_acronym>
        <doi>10.17487/RFC4287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4288</doc-id>
        <title>Media Type Specifications and Registration Procedures</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>media types</kw>
        </keywords>
        <abstract><p>This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-freed-media-type-reg-05</draft>
        <obsoletes>
            <doc-id>RFC2048</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6838</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4288</errata-url>
        <doi>10.17487/RFC4288</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4289</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>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>media</kw>
            <kw>types</kw>
            <kw>external</kw>
            <kw>body</kw>
            <kw>access</kw>
            <kw>content-transfer-encodings</kw>
        </keywords>
        <abstract><p>This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-freed-mime-p4-07</draft>
        <obsoletes>
            <doc-id>RFC2048</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0013</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4289</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4290</doc-id>
        <title>Suggested Practices for Registration of Internationalized Domain Names (IDN)</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>chinese domain names</kw>
            <kw>japanese domain names</kw>
            <kw>korean domain names</kw>
        </keywords>
        <abstract><p>This document explores the issues in the registration of internationalized domain names (IDNs).  The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names.  To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations.  This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-klensin-reg-guidelines-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4290</errata-url>
        <doi>10.17487/RFC4290</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4291</doc-id>
        <title>IP Version 6 Addressing Architecture</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>unicast</kw>
            <kw>anycast</kw>
            <kw>multicast</kw>
            <kw>node</kw>
        </keywords>
        <abstract><p>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.</p><p> This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-addr-arch-v4-04</draft>
        <obsoletes>
            <doc-id>RFC3513</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5952</doc-id>
            <doc-id>RFC6052</doc-id>
            <doc-id>RFC7136</doc-id>
            <doc-id>RFC7346</doc-id>
            <doc-id>RFC7371</doc-id>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4291</errata-url>
        <doi>10.17487/RFC4291</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4292</doc-id>
        <title>IP Forwarding Table MIB</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>TABLE-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>Internet Protocol</kw>
        </keywords>
        <abstract><p>This document 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 related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner.  This document obsoletes RFC 2096. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-rfc2096-update-07</draft>
        <obsoletes>
            <doc-id>RFC2096</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4293</doc-id>
        <title>Management Information Base for the Internet Protocol (IP)</title>
        <author>
            <name>S. Routhier</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>122</page-count>
        <keywords>
            <kw>MIB-IP</kw>
            <kw>IP</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>MIB</kw>
            <kw>ipv6</kw>
            <kw>ICMPv6-MIB</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ip mib</kw>
            <kw>ipv4 mib</kw>
            <kw>ipv6 mib</kw>
            <kw>icmp mib</kw>
            <kw>icmpv6 mib</kw>
        </keywords>
        <abstract><p>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 Internet Protocol (IP) in an IP version independent manner.  This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-rfc2011-update-10</draft>
        <obsoletes>
            <doc-id>RFC2011</doc-id>
            <doc-id>RFC2465</doc-id>
            <doc-id>RFC2466</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4293</errata-url>
        <doi>10.17487/RFC4293</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4294</doc-id>
        <title>IPv6 Node Requirements</title>
        <author>
            <name>J. Loughney</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This document defines requirements for IPv6 nodes.  It is expected that IPv6 will be deployed in a wide range of devices and situations.  Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipv6-node-requirements-11</draft>
        <obsoleted-by>
            <doc-id>RFC6434</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5095</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4294</errata-url>
        <doi>10.17487/RFC4294</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4295</doc-id>
        <title>Mobile IPv6 Management Information Base</title>
        <author>
            <name>G. Keeni</name>
        </author>
        <author>
            <name>K. Koide</name>
        </author>
        <author>
            <name>K. Nagami</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>mipv6</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community.  In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-mipv6-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4295</errata-url>
        <doi>10.17487/RFC4295</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4296</doc-id>
        <title>The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols</title>
        <author>
            <name>S. Bailey</name>
        </author>
        <author>
            <name>T. Talpey</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>rddp</kw>
            <kw>warp</kw>
        </keywords>
        <abstract><p>This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports.  This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols.  DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA).  RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rddp-arch-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4296</errata-url>
        <doi>10.17487/RFC4296</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4297</doc-id>
        <title>Remote Direct Memory Access (RDMA) over IP Problem Statement</title>
        <author>
            <name>A. Romanow</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>T. Talpey</name>
        </author>
        <author>
            <name>S. Bailey</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>overhead</kw>
            <kw>copy avoidance</kw>
        </keywords>
        <abstract><p>Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.</p><p> This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rddp-problem-statement-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <doi>10.17487/RFC4297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4298</doc-id>
        <title>RTP Payload Format for BroadVoice Speech Codecs</title>
        <author>
            <name>J.-H. Chen</name>
        </author>
        <author>
            <name>W. Lee</name>
        </author>
        <author>
            <name>J. Thyssen</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>real time transport</kw>
            <kw>narroband</kw>
            <kw>wideband</kw>
            <kw>bv16 broadvoice16</kw>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
        </keywords>
        <abstract><p>This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs.  The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification.  The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-bv-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4298</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4299</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4300</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4301</doc-id>
        <title>Security Architecture for the Internet Protocol</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>K. Seo</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>encapsulation</kw>
            <kw>IP</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>IP-layer</kw>
            <kw>ip authentication header</kw>
            <kw>ip security</kw>
            <kw>IPsec</kw>
            <kw>confidentiality</kw>
            <kw>authentication integrity</kw>
            <kw>anti-replay</kw>
            <kw>ah</kw>
            <kw>esp</kw>
            <kw>encapsulating security payload</kw>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
            <kw>ikev2</kw>
            <kw>esn</kw>
            <kw>extended sequence number</kw>
        </keywords>
        <abstract><p>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer.  This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-rfc2401bis-06</draft>
        <obsoletes>
            <doc-id>RFC2401</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3168</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6040</doc-id>
            <doc-id>RFC7619</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4301</errata-url>
        <doi>10.17487/RFC4301</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4302</doc-id>
        <title>IP Authentication Header</title>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <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>
            <kw>ip security</kw>
            <kw>confidentiality</kw>
            <kw>authentication</kw>
            <kw>integrity</kw>
            <kw>anti-replay</kw>
            <kw>ah</kw>
            <kw>esp</kw>
            <kw>encapsulating security payload</kw>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
            <kw>ikev2</kw>
            <kw>esn</kw>
            <kw>extended sequence number</kw>
        </keywords>
        <abstract><p>This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6.  This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-rfc2402bis-10</draft>
        <obsoletes>
            <doc-id>RFC2402</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4302</errata-url>
        <doi>10.17487/RFC4302</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4303</doc-id>
        <title>IP Encapsulating Security Payload (ESP)</title>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <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>
            <kw>ip security</kw>
            <kw>confidentiality</kw>
            <kw>authentication</kw>
            <kw>integrity</kw>
            <kw>anti-replay</kw>
            <kw>ah</kw>
            <kw>ip authentication header</kw>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
            <kw>ikev2</kw>
            <kw>esn</kw>
            <kw>extended sequence number</kw>
        </keywords>
        <abstract><p>This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-esp-v3-10</draft>
        <obsoletes>
            <doc-id>RFC2406</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4303</errata-url>
        <doi>10.17487/RFC4303</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4304</doc-id>
        <title>Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)</title>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ipsecurity</kw>
            <kw>anti-replay</kw>
            <kw>ah</kw>
            <kw>ip authentication header</kw>
            <kw>esp</kw>
            <kw>encapsulating security payload</kw>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
            <kw>ikev2</kw>
        </keywords>
        <abstract><p>The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay.  This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP).  These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-esn-addendum-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <doi>10.17487/RFC4304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4305</doc-id>
        <title>Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ESP</kw>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>mechanism</kw>
            <kw>header</kw>
            <kw>security</kw>
            <kw>architecture</kw>
            <kw>payload</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulating</kw>
            <kw>ipv4</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA).  To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.  This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-esp-ah-algorithms-02</draft>
        <obsoletes>
            <doc-id>RFC2402</doc-id>
            <doc-id>RFC2406</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4835</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4305</errata-url>
        <doi>10.17487/RFC4305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4306</doc-id>
        <title>Internet Key Exchange (IKEv2) Protocol</title>
        <author>
            <name>C. Kaufman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <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>
            <kw>cryptography</kw>
            <kw>authentication</kw>
            <kw>IKE</kw>
            <kw>oakley</kw>
            <kw>isakmp</kw>
        </keywords>
        <abstract><p>This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).</p><p> This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.</p><p> Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-ikev2-17</draft>
        <obsoletes>
            <doc-id>RFC2407</doc-id>
            <doc-id>RFC2408</doc-id>
            <doc-id>RFC2409</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5996</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5282</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4306</errata-url>
        <doi>10.17487/RFC4306</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4307</doc-id>
        <title>Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)</title>
        <author>
            <name>J. Schiller</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
        </keywords>
        <abstract><p>The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association.  However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.  This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-ikev2-algorithms-05</draft>
        <obsoleted-by>
            <doc-id>RFC8247</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4307</errata-url>
        <doi>10.17487/RFC4307</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4308</doc-id>
        <title>Cryptographic Suites for IPsec</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
            <kw>ikev2</kw>
            <kw>security algorithms</kw>
            <kw>ikev1</kw>
        </keywords>
        <abstract><p>The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder.  There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms.  This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-ui-suites-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4308</errata-url>
        <doi>10.17487/RFC4308</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4309</doc-id>
        <title>Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>cbc-mac mode</kw>
            <kw>initialization vector</kw>
            <kw>iv</kw>
            <kw>confidentiality</kw>
            <kw>data origin authentication</kw>
            <kw>connectionless integrity</kw>
        </keywords>
        <abstract><p>This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-ciph-aes-ccm-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4309</errata-url>
        <doi>10.17487/RFC4309</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4310</doc-id>
        <title>Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>dnssec</kw>
            <kw>domain name system security extensions</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-epp-secdns-08</draft>
        <obsoleted-by>
            <doc-id>RFC5910</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4310</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4311</doc-id>
        <title>IPv6 Host-to-Router Load Sharing</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>November</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>conceptual sending algorithm</kw>
        </keywords>
        <abstract><p>The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice.  This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-host-load-sharing-04</draft>
        <updates>
            <doc-id>RFC2461</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4311</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4312</doc-id>
        <title>The Camellia Cipher Algorithm and Its Use With IPsec</title>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>S. Moriai</name>
        </author>
        <author>
            <name>M. Kanda</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>cipher block chaining mode</kw>
            <kw>initialization vector</kw>
            <kw>iv</kw>
            <kw>esp</kw>
            <kw>encapsulating security payload</kw>
            <kw>ip security</kw>
        </keywords>
        <abstract><p>This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit Initialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kato-ipsec-ciph-camellia-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4312</errata-url>
        <doi>10.17487/RFC4312</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4313</doc-id>
        <title>Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources</title>
        <author>
            <name>D. Oran</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>speech processing</kw>
            <kw>audio streams</kw>
            <kw>si</kw>
            <kw>speaker identification</kw>
            <kw>sv</kw>
            <kw>speaker verification</kw>
            <kw>tts</kw>
            <kw>text to speech</kw>
        </keywords>
        <abstract><p>This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams.  By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS).  Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams.  However, speech processing presents additional requirements that none of the extant IETF protocols address.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-speechsc-reqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speechsc</wg_acronym>
        <doi>10.17487/RFC4313</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4314</doc-id>
        <title>IMAP4 Access Control List (ACL) Extension</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IMAP4-ACL</kw>
            <kw>Control</kw>
            <kw>List</kw>
            <kw>internet message access protocol</kw>
        </keywords>
        <abstract><p>The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.</p><p> This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imapext-2086upd-08</draft>
        <obsoletes>
            <doc-id>RFC2086</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4314</errata-url>
        <doi>10.17487/RFC4314</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4315</doc-id>
        <title>Internet Message Access Protocol (IMAP) - UIDPLUS extension</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IMAP4UIDPL</kw>
            <kw>internet message access protocol</kw>
            <kw>disconnected</kw>
            <kw>operation</kw>
        </keywords>
        <abstract><p>The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations.  The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-crispin-imap-rfc2359bis-04</draft>
        <obsoletes>
            <doc-id>RFC2359</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4315</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4316</doc-id>
        <title>Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>datatying</kw>
            <kw>propfind</kw>
        </keywords>
        <abstract><p>This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping.  Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-reschke-webdav-property-datatypes-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4316</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4317</doc-id>
        <title>Session Description Protocol (SDP) Offer/Answer Examples</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document gives examples of Session Description Protocol (SDP) offer/answer exchanges.  Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams.  The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types.  Common Third Party Call Control (3pcc) examples are also given.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mmusic-offer-answer-examples-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4318</doc-id>
        <title>Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>simple network management protocol</kw>
            <kw>transparent bridging</kw>
            <kw>rstp-mib</kw>
        </keywords>
        <abstract><p>This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments.  The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bridge-rstpmib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <doi>10.17487/RFC4318</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4319</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</title>
        <author>
            <name>C. Sikes</name>
        </author>
        <author>
            <name>B. Ray</name>
        </author>
        <author>
            <name>R. Abbi</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>hdsl2-shdsl-line-mib</kw>
            <kw>interfaces</kw>
        </keywords>
        <abstract><p>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 High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.  This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276).  This document obsoletes RFC 3276. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-adslmib-gshdslbis-11</draft>
        <obsoletes>
            <doc-id>RFC3276</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4319</errata-url>
        <doi>10.17487/RFC4319</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4320</doc-id>
        <title>Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction.  These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic.  They also improve the robustness of SIP networks when elements stop responding.  These changes update behavior defined in RFC 3261. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-sparks-sip-nit-actions-03</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4320</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4321</doc-id>
        <title>Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-sparks-sip-nit-problems-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4321</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4322</doc-id>
        <title>Opportunistic Encryption using the Internet Key Exchange (IKE)</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>D.H. Redelmeier</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>oe</kw>
            <kw>linux frees/wan</kw>
            <kw>ipsec</kw>
            <kw>dns</kw>
            <kw>domain name space</kw>
            <kw>dns security</kw>
        </keywords>
        <abstract><p>This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.</p><p> As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-richardson-ipsec-opportunistic-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4322</errata-url>
        <doi>10.17487/RFC4322</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4323</doc-id>
        <title>Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)</title>
        <author>
            <name>M. Patrick</name>
        </author>
        <author>
            <name>W. Murwin</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>89</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>cm</kw>
            <kw>cable modem</kw>
            <kw>cmts</kw>
            <kw>cable modem termination system</kw>
            <kw>docs-ietf-qos-mib</kw>
        </keywords>
        <abstract><p>This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-qos-mib-12</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4324</doc-id>
        <title>Calendar Access Protocol (CAP)</title>
        <author>
            <name>D. Royer</name>
        </author>
        <author>
            <name>G. Babics</name>
        </author>
        <author>
            <name>S. Mansour</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>131</page-count>
        <keywords>
            <kw>calendar user</kw>
            <kw>cu</kw>
            <kw>calendar user agent</kw>
            <kw>cua</kw>
            <kw>ical</kw>
            <kw>calender store</kw>
            <kw>cs</kw>
        </keywords>
        <abstract><p>The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS).  At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed.  In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work.  Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-royer-calsch-cap-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4324</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4325</doc-id>
        <title>Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>issuer certificate</kw>
        </keywords>
        <abstract><p>This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension.  RFC 3280 defines the Authority Information Access certificate extension using the same syntax.  The CRL extension provides a means of discovering and retrieving CRL issuer certificates. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-crlaia-03</draft>
        <obsoleted-by>
            <doc-id>RFC5280</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4326</doc-id>
        <title>Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>B. Collini-Nocker</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.</p><p> This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipdvb-ule-06</draft>
        <updated-by>
            <doc-id>RFC7280</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipdvb</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4326</errata-url>
        <doi>10.17487/RFC4326</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4327</doc-id>
        <title>Link Management Protocol (LMP) Management Information Base (MIB)</title>
        <author>
            <name>M. Dubuc</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>J. Lang</name>
        </author>
        <author>
            <name>E. McGinnis</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>lmp-mib</kw>
        </keywords>
        <abstract><p>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 modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lmp-mib-10</draft>
        <obsoleted-by>
            <doc-id>RFC4631</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4327</errata-url>
        <doi>10.17487/RFC4327</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4328</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control</title>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>otn</kw>
            <kw>optical transport networks</kw>
            <kw>pre-otn</kw>
        </keywords>
        <abstract><p>This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents.  It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-g709-09</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7139</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4328</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4329</doc-id>
        <title>Scripting Media Types</title>
        <author>
            <name>B. Hoehrmann</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>JavaScript</kw>
            <kw>EMACScript</kw>
            <kw>mime</kw>
            <kw>script</kw>
            <kw>subtype</kw>
        </keywords>
        <abstract><p>This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hoehrmann-script-types-03</draft>
        <obsoleted-by>
            <doc-id>RFC9239</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4330</doc-id>
        <title>Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>time</kw>
            <kw>computer</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract><p>This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.</p><p> This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mills-sntp-v4-01</draft>
        <obsoletes>
            <doc-id>RFC2030</doc-id>
            <doc-id>RFC1769</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5905</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4330</errata-url>
        <doi>10.17487/RFC4330</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4331</doc-id>
        <title>Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections</title>
        <author>
            <name>B. Korver</name>
        </author>
        <author>
            <name>L. Dusseault</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>webdav</kw>
        </keywords>
        <abstract><p>Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations.  This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-webdav-quota-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <doi>10.17487/RFC4331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4332</doc-id>
        <title>Cisco's Mobile IPv4 Host Configuration Extensions</title>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>A. Patel</name>
        </author>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>E. Klovning</name>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
            <kw>dhcp</kw>
            <kw>point-to-point</kw>
            <kw>ip control protocol</kw>
            <kw>ppp</kw>
            <kw>ipcp</kw>
        </keywords>
        <abstract><p>An IP device requires basic host configuration to be able to communicate.  For example, it will typically require an IP address and the address of a DNS server.  This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol (PPP/IPCP).  However, both DHCP and PPP/IPCP provide host configuration based on the access network.  In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network.  The information to configure the host needs to be based on the home network.  This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-leung-cisco-mip4-host-config-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4332</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4333</doc-id>
        <title>The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process</title>
        <author>
            <name>G. Huston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Wijnen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>iad</kw>
            <kw>iasa</kw>
            <kw>ietf administrative support activity</kw>
            <kw>ietf administrative director</kw>
        </keywords>
        <abstract><p>This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-iab-iesg-iaoc-selection-03</draft>
        <obsoleted-by>
            <doc-id>RFC8711</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4333</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4334</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>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>eap</kw>
            <kw>extensible authentication protocol</kw>
            <kw>wireless lan</kw>
            <kw>wlan</kw>
            <kw>system service identifier</kw>
            <kw>ssid</kw>
        </keywords>
        <abstract><p>This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs).  This document obsoletes RFC 3770. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc3770bis-03</draft>
        <obsoletes>
            <doc-id>RFC3770</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4334</errata-url>
        <doi>10.17487/RFC4334</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4335</doc-id>
        <title>The Secure Shell (SSH) Session Channel Break Extension</title>
        <author>
            <name>J. Galbraith</name>
        </author>
        <author>
            <name>P. Remaker</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-break-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4335</errata-url>
        <doi>10.17487/RFC4335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4336</doc-id>
        <title>Problem Statement for the Datagram Congestion Control Protocol (DCCP)</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>E. Kohler</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control.  DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dccp-problem-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC4336</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4337</doc-id>
        <title>MIME Type Registration for MPEG-4</title>
        <author>
            <name>Y. Lim</name>
        </author>
        <author>
            <name>D. Singer</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines the standard MIME types associated with MP4 files.  It also recommends use of registered MIME types according to the type of contents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-lim-mpeg4-mime-03</draft>
        <updated-by>
            <doc-id>RFC6381</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4337</errata-url>
        <doi>10.17487/RFC4337</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4338</doc-id>
        <title>Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>C. Carlson</name>
        </author>
        <author>
            <name>R. Nixon</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>link local address</kw>
            <kw>link-local address</kw>
        </keywords>
        <abstract><p>This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.</p><p> This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-ip-over-fibre-channel-03</draft>
        <obsoletes>
            <doc-id>RFC3831</doc-id>
            <doc-id>RFC2625</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5494</doc-id>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC4338</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4339</doc-id>
        <title>IPv6 Host Configuration of DNS Server Information Approaches</title>
        <author>
            <name>J. Jeong</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>domain name server</kw>
            <kw>internet protocol</kw>
            <kw>address configuration</kw>
            <kw>dhcpv6</kw>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>This document describes three approaches for IPv6 recursive DNS server address configuration.  It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers.  Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsop-ipv6-dns-configuration-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4339</errata-url>
        <doi>10.17487/RFC4339</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4340</doc-id>
        <title>Datagram Congestion Control Protocol (DCCP)</title>
        <author>
            <name>E. Kohler</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>129</page-count>
        <keywords>
            <kw>transport protocol</kw>
        </keywords>
        <abstract><p>The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams.  DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-spec-11</draft>
        <updated-by>
            <doc-id>RFC5595</doc-id>
            <doc-id>RFC5596</doc-id>
            <doc-id>RFC6335</doc-id>
            <doc-id>RFC6773</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4340</errata-url>
        <doi>10.17487/RFC4340</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4341</doc-id>
        <title>Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>E. Kohler</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>transport protocol</kw>
            <kw>amid</kw>
            <kw>additive increase multiplicative decrease</kw>
        </keywords>
        <abstract><p>This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP).  CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-ccid2-10</draft>
        <updated-by>
            <doc-id>RFC8311</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC4341</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4342</doc-id>
        <title>Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>E. Kohler</name>
        </author>
        <author>
            <name>J. Padhye</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>transport protocol</kw>
            <kw>ecn</kw>
            <kw>explicit congestion notification</kw>
            <kw>ccid3</kw>
        </keywords>
        <abstract><p>This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP).  CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-ccid3-11</draft>
        <updated-by>
            <doc-id>RFC5348</doc-id>
            <doc-id>RFC6323</doc-id>
            <doc-id>RFC8311</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4342</errata-url>
        <doi>10.17487/RFC4342</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4343</doc-id>
        <title>Domain Name System (DNS) Case Insensitivity Clarification</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Domain Name System (DNS) names are "case insensitive".  This document explains exactly what that means and provides a clear specification of the rules.  This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-insensitive-06</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC2181</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5890</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4343</errata-url>
        <doi>10.17487/RFC4343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4344</doc-id>
        <title>The Secure Shell (SSH) Transport Layer Encryption Modes</title>
        <author>
            <name>M. Bellare</name>
        </author>
        <author>
            <name>T. Kohno</name>
        </author>
        <author>
            <name>C. Namprempre</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>rekey</kw>
        </keywords>
        <abstract><p>Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.</p><p> This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-newmodes-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <doi>10.17487/RFC4344</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4345</doc-id>
        <title>Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol</title>
        <author>
            <name>B. Harris</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>arcfour cipher</kw>
            <kw>key scheduling algorithm</kw>
        </keywords>
        <abstract><p>This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-harris-ssh-arcfour-fixes-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4345</errata-url>
        <doi>10.17487/RFC4345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4346</doc-id>
        <title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
        <author>
            <name>T. Dierks</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>87</page-count>
        <abstract><p>This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.</p></abstract>
        <draft>draft-ietf-tls-rfc2246-bis-13</draft>
        <obsoletes>
            <doc-id>RFC2246</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5246</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC4366</doc-id>
            <doc-id>RFC4680</doc-id>
            <doc-id>RFC4681</doc-id>
            <doc-id>RFC5746</doc-id>
            <doc-id>RFC6176</doc-id>
            <doc-id>RFC7465</doc-id>
            <doc-id>RFC7507</doc-id>
            <doc-id>RFC7919</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4346</errata-url>
        <doi>10.17487/RFC4346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4347</doc-id>
        <title>Datagram Transport Layer Security</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>N. Modadugu</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>dtls</kw>
        </keywords>
        <abstract><p>This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.</p></abstract>
        <draft>draft-rescorla-dtls-05</draft>
        <obsoleted-by>
            <doc-id>RFC6347</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5746</doc-id>
            <doc-id>RFC7507</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4347</errata-url>
        <doi>10.17487/RFC4347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4348</doc-id>
        <title>Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec</title>
        <author>
            <name>S. Ahmadi</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>speech codec</kw>
            <kw>variable-rate multicode wideband speech codec</kw>
        </keywords>
        <abstract><p>This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.</p><p> VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-vmr-wb-11</draft>
        <updated-by>
            <doc-id>RFC4424</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4348</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4349</doc-id>
        <title>High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>pseudowire</kw>
        </keywords>
        <abstract><p>The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks.  This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-pwe3-hdlc-07</draft>
        <updated-by>
            <doc-id>RFC5641</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC4349</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4350</doc-id>
        <title>A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government</title>
        <author>
            <name>F. Hendrikx</name>
        </author>
        <author>
            <name>C. Wallis</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>nid</kw>
            <kw>namespace identification</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hendrikx-wallis-urn-nzl-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4350</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4351</doc-id>
        <title>Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream</title>
        <author>
            <name>G. Hellstrom</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>itu-t recommendation t.140</kw>
        </keywords>
        <abstract><p>This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.</p><p> One payload format is described for transmitting audio and text data within a single RTP session.</p><p> This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-ietf-avt-audio-t140c-00</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4351</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4352</doc-id>
        <title>RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec</title>
        <author>
            <name>J. Sjoberg</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>A. Lakaniemi</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>audio signals</kw>
        </keywords>
        <abstract><p>This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals.  The AMR-WB+ codec is an audio extension of the AMR-WB speech codec.  It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech.  A media type registration for AMR-WB+ is included in this specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-amrwbplus-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4352</errata-url>
        <doi>10.17487/RFC4352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4353</doc-id>
        <title>A Framework for Conferencing with the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents.  These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents.  Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious.  Communications sessions with multiple participants, generally known as conferencing, are more complicated.  This document defines a framework for how such conferencing can occur.  This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-conferencing-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4353</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4354</doc-id>
        <title>A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>oma</kw>
            <kw>open mobile alliance</kw>
        </keywords>
        <abstract><p>The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc.  This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service.  This SIP event package is applicable to the PoC service and may not be applicable to the general Internet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-garcia-sipping-poc-isb-am-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4354</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4355</doc-id>
        <title>IANA Registration for Enumservices email, fax, mms, ems, and sms</title>
        <author>
            <name>R. Brandner</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <author>
            <name>R. Stastny</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-msg-05</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4355</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4356</doc-id>
        <title>Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>cellular telephone</kw>
            <kw>x-mms</kw>
        </keywords>
        <abstract><p>The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.</p><p> One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.</p><p> This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-mms-mapping-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC4356</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4357</doc-id>
        <title>Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms</title>
        <author>
            <name>V. Popov</name>
        </author>
        <author>
            <name>I. Kurepkin</name>
        </author>
        <author>
            <name>S. Leontiev</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>cpalgs</kw>
            <kw>public-key</kw>
            <kw>one-way</kw>
            <kw>hash</kw>
            <kw>block</kw>
            <kw>cipher</kw>
            <kw>encyption</kw>
            <kw>decryption</kw>
            <kw>mac</kw>
            <kw>hmac</kw>
            <kw>prf</kw>
            <kw>wrap</kw>
            <kw>unwrap</kw>
            <kw>ukm</kw>
            <kw>kek</kw>
            <kw>key</kw>
            <kw>parameter</kw>
            <kw>derivation</kw>
            <kw>digest</kw>
            <kw>cbc</kw>
            <kw>counter</kw>
            <kw>mode</kw>
            <kw>digital</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-popov-cryptopro-cpalgs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4357</errata-url>
        <doi>10.17487/RFC4357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4358</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)</title>
        <author>
            <name>D. Smith</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>nid</kw>
            <kw>namespace identifier</kw>
            <kw>omna</kw>
            <kw>open mobile naming authority</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Open Mobile Alliance (OMA).  OMA defines and manages resources that utilize this URN name model.  Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-smith-oma-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4358</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4359</doc-id>
        <title>The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ip encapsulating security payload</kw>
            <kw>digital signature</kw>
        </keywords>
        <abstract><p>This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302.  The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property.  One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-ipsec-signatures-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4359</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4360</doc-id>
        <title>BGP Extended Communities Attribute</title>
        <author>
            <name>S. Sangli</name>
        </author>
        <author>
            <name>D. Tappan</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document describes the "extended community" BGP-4 attribute.  This attribute provides a mechanism for labeling information carried in BGP-4.  These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-bgp-ext-communities-09</draft>
        <updated-by>
            <doc-id>RFC7153</doc-id>
            <doc-id>RFC7606</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4360</errata-url>
        <doi>10.17487/RFC4360</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4361</doc-id>
        <title>Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>B. Sommerfeld</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>dhcpv6</kw>
        </keywords>
        <abstract><p>This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol.  This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-3315id-for-v4-05</draft>
        <updates>
            <doc-id>RFC2131</doc-id>
            <doc-id>RFC2132</doc-id>
            <doc-id>RFC3315</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4361</errata-url>
        <doi>10.17487/RFC4361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4362</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>
        <author>
            <name>K. Sandlund</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>user datagram protocol</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>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 related to the usage of the header-free packet format.  This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-rfc3242bis-01</draft>
        <obsoletes>
            <doc-id>RFC3242</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4815</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4362</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4363</doc-id>
        <title>Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>mac bridges</kw>
            <kw>traffic classes</kw>
            <kw>enhanced multicast filtering</kw>
            <kw>p-bridge-mib</kw>
            <kw>q-bridge-mib</kw>
        </keywords>
        <abstract><p>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 two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM).</p><p> Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.</p><p> This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bridge-ext-v2-07</draft>
        <obsoletes>
            <doc-id>RFC2674</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bridge</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4363</errata-url>
        <doi>10.17487/RFC4363</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4364</doc-id>
        <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>service provider</kw>
            <kw>ip backbone</kw>
            <kw>ce router</kw>
            <kw>pe router</kw>
            <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><p>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers.  This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other.  Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-rfc2547bis-03</draft>
        <obsoletes>
            <doc-id>RFC2547</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4577</doc-id>
            <doc-id>RFC4684</doc-id>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4364</errata-url>
        <doi>10.17487/RFC4364</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4365</doc-id>
        <title>Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l3vpn-as2547-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4365</errata-url>
        <doi>10.17487/RFC4365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4366</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>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>layer</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>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.</p><p> The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-rfc3546bis-02</draft>
        <obsoletes>
            <doc-id>RFC3546</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC6066</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4346</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5746</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4366</errata-url>
        <doi>10.17487/RFC4366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4367</doc-id>
        <title>What's in a Name: False Assumptions about DNS Names</title>
        <author>
            <name>J. Rosenberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses.  These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users.  Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on.  There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names.  Those assumptions can often be false, resulting in a variety of failure conditions.  This document discusses this problem in more detail and makes recommendations on how it can be avoided.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-dns-assumptions-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4367</errata-url>
        <doi>10.17487/RFC4367</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4368</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>mpls-lc-atm-std-mib</kw>
            <kw>mpls-lc-fr-std-mib</kw>
        </keywords>
        <abstract><p>This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-lc-if-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4368</errata-url>
        <doi>10.17487/RFC4368</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4369</doc-id>
        <title>Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)</title>
        <author>
            <name>K. Gibbons</name>
        </author>
        <author>
            <name>C. Monia</name>
        </author>
        <author>
            <name>J. Tseng</name>
        </author>
        <author>
            <name>F. Travostino</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>ifcp gateway</kw>
            <kw>ifcp-mgmt-mib</kw>
        </keywords>
        <abstract><p>The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components.  The iFCP protocol is used between iFCP Gateways.  This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-ifcp-mib-07</draft>
        <obsoleted-by>
            <doc-id>RFC6173</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC4369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4370</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control</title>
        <author>
            <name>R. Weltman</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>proxy authorization control</kw>
        </keywords>
        <abstract><p>This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control.  The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-weltman-ldapv3-proxy-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4370</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4371</doc-id>
        <title>BCP 101 Update for IPR Trust</title>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Lynch</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document updates BCP 101 to take account of the new IETF Intellectual Property Trust.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-carpenter-bcp101-update-03</draft>
        <obsoleted-by>
            <doc-id>RFC8714</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4071</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4371</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4372</doc-id>
        <title>Chargeable User Identity</title>
        <author>
            <name>F. Adrangi</name>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>radius</kw>
            <kw>remote authentication dial-in user service</kw>
            <kw>roaming transaction</kw>
            <kw>home network</kw>
        </keywords>
        <abstract><p>This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity.  This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-chargeable-user-id-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC4372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4373</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)</title>
        <author>
            <name>R. Harrison</name>
        </author>
        <author>
            <name>J. Sermersheim</name>
        </author>
        <author>
            <name>Y. Dong</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.</p><p> The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-rharrison-lburp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4373</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4374</doc-id>
        <title>The application/xv+xml Media Type</title>
        <author>
            <name>G. McCobb</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>mime</kw>
            <kw>sub-type</kw>
            <kw>media descriptor</kw>
            <kw>xhtml+voice</kw>
        </keywords>
        <abstract><p>This document describes the registration of the MIME sub-type application/xv+xml.  This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mccobb-xv-media-type-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4374</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4375</doc-id>
        <title>Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain</title>
        <author>
            <name>K. Carlberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>resource</kw>
            <kw>transit domain</kw>
            <kw>stub domain</kw>
        </keywords>
        <abstract><p>This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain.  This document focuses on a specific set of administrative constraints and scope.  Solutions to these requirements are not presented in this document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ieprep-domain-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <doi>10.17487/RFC4375</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4376</doc-id>
        <title>Requirements for Floor Control Protocols</title>
        <author>
            <name>P. Koskelainen</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>X. Wu</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>shared resources</kw>
            <kw>multiparty conferences</kw>
        </keywords>
        <abstract><p>Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.  Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.  This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-xcon-floor-control-req-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC4376</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4377</doc-id>
        <title>Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>M. Morrow</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>D. Allan</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services.  These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-oam-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4377</errata-url>
        <doi>10.17487/RFC4377</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4378</doc-id>
        <title>A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)</title>
        <author>
            <name>D. Allan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>data plane</kw>
            <kw>fcaps</kw>
        </keywords>
        <abstract><p>This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS).  The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-oam-frmwk-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4378</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4379</doc-id>
        <title>Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>data plane</kw>
        </keywords>
        <abstract><p>This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs).  There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-13</draft>
        <obsoleted-by>
            <doc-id>RFC8029</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1122</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5462</doc-id>
            <doc-id>RFC6424</doc-id>
            <doc-id>RFC6425</doc-id>
            <doc-id>RFC6426</doc-id>
            <doc-id>RFC6829</doc-id>
            <doc-id>RFC7506</doc-id>
            <doc-id>RFC7537</doc-id>
            <doc-id>RFC7743</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4379</errata-url>
        <doi>10.17487/RFC4379</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4380</doc-id>
        <title>Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service.  Running the service requires the help of "Teredo servers" and "Teredo relays".  The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet.  The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-huitema-v6ops-teredo-05</draft>
        <updated-by>
            <doc-id>RFC5991</doc-id>
            <doc-id>RFC6081</doc-id>
            <doc-id>RFC9601</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4380</errata-url>
        <doi>10.17487/RFC4380</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4381</doc-id>
        <title>Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)</title>
        <author>
            <name>M. Behringer</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>service provider</kw>
            <kw>atm</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>frame relay</kw>
        </keywords>
        <abstract><p>This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.</p><p> The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-behringer-mpls-security-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4381</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4382</doc-id>
        <title>MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. van der Linde</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>multiprotocol label switching</kw>
            <kw>label switching router</kw>
            <kw>lsr</kw>
            <kw>mpls-l3vpn-std-mib</kw>
        </keywords>
        <abstract><p>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 to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-mpls-vpn-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4382</errata-url>
        <doi>10.17487/RFC4382</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4383</doc-id>
        <title>The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)</title>
        <author>
            <name>M. Baugher</name>
        </author>
        <author>
            <name>E. Carrara</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>multicast data stream</kw>
            <kw>broadcast data stream</kw>
        </keywords>
        <abstract><p>This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-srtp-tesla-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4383</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4384</doc-id>
        <title>BGP Communities for Data Collection</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes.  Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers.  With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system.  This memo defines standard (outbound) communities and their encodings for export to BGP route collectors.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-grow-collection-communities-06</draft>
        <is-also>
            <doc-id>BCP0114</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4384</errata-url>
        <doi>10.17487/RFC4384</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4385</doc-id>
        <title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>packet switched network</kw>
            <kw>pseudowire associated channel header</kw>
        </keywords>
        <abstract><p>This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header.  The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-cw-06</draft>
        <updated-by>
            <doc-id>RFC5586</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4385</errata-url>
        <doi>10.17487/RFC4385</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4386</doc-id>
        <title>Internet X.509 Public Key Infrastructure Repository Locator Service</title>
        <author>
            <name>S. Boeyen</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>pki</kw>
            <kw>public key infrastructure</kw>
            <kw>dns srv</kw>
        </keywords>
        <abstract><p>This document defines a Public Key Infrastructure (PKI) repository locator service.  The service makes use of DNS SRV records defined in accordance with RFC 2782.  The service enables certificate-using systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pkix-pkixrep-04</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4386</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4387</doc-id>
        <title>Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP</title>
        <author>
            <name>P. Gutmann</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>pki</kw>
            <kw>hypertext transfer protocol</kw>
        </keywords>
        <abstract><p>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 Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories.  Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-certstore-http-09</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4388</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP) Leasequery</title>
        <author>
            <name>R. Woundy</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>dhcpv4</kw>
            <kw>ip address</kw>
        </keywords>
        <abstract><p>A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients.  Other processes and devices that already make use of DHCPv4 may need to access this information.  The leasequery protocol provides these processes and devices a lightweight way to access IP address information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-leasequery-09</draft>
        <updated-by>
            <doc-id>RFC6148</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4388</errata-url>
        <doi>10.17487/RFC4388</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4389</doc-id>
        <title>Neighbor Discovery Proxies (ND Proxy)</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>M. Talwar</name>
        </author>
        <author>
            <name>C. Patel</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ndproxy</kw>
        </keywords>
        <abstract><p>Bridging multiple links into a single entity has several operational advantages.  A single subnet prefix is sufficient to support multiple physical links.  There is no need to allocate subnet numbers to the different networks, simplifying management.  Bridging some types of media requires network-layer support, however.  This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ipv6-ndproxy-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4389</errata-url>
        <doi>10.17487/RFC4389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4390</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP) over InfiniBand</title>
        <author>
            <name>V. Kashyap</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>bootstrap</kw>
            <kw>boot</kw>
            <kw>ipoib</kw>
        </keywords>
        <abstract><p>IP over Infiniband (IPoIB) link-layer address is 20 octets long.  This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message.  The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network.  This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipoib-dhcp-over-infiniband-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipoib</wg_acronym>
        <doi>10.17487/RFC4390</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4391</doc-id>
        <title>Transmission of IP over InfiniBand (IPoIB)</title>
        <author>
            <name>J. Chu</name>
        </author>
        <author>
            <name>V. Kashyap</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>address resolution protocol</kw>
            <kw>arp</kw>
            <kw>ib</kw>
        </keywords>
        <abstract><p>This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB).  It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets.  The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses.  In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipoib-ip-over-infiniband-09</draft>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipoib</wg_acronym>
        <doi>10.17487/RFC4391</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4392</doc-id>
        <title>IP over InfiniBand (IPoIB) Architecture</title>
        <author>
            <name>V. Kashyap</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>ib</kw>
            <kw>ipv4</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>InfiniBand is a high-speed, channel-based interconnect between systems and devices.</p><p> This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipoib-architecture-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipoib</wg_acronym>
        <doi>10.17487/RFC4392</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4393</doc-id>
        <title>MIME Type Registrations for 3GPP2 Multimedia Files</title>
        <author>
            <name>H. Garudadri</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>third-generation partnership project 2</kw>
        </keywords>
        <abstract><p>This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-garudadri-avt-3gpp2-mime-02</draft>
        <updated-by>
            <doc-id>RFC6381</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4393</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4394</doc-id>
        <title>A Transport Network View of the Link Management Protocol (LMP)</title>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>O. Aboul-Magd</name>
        </author>
        <author>
            <name>D. Brungard</name>
        </author>
        <author>
            <name>J. Lang</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>gmpls</kw>
            <kw>ason</kw>
            <kw>discovery</kw>
            <kw>sdh</kw>
            <kw>otn</kw>
            <kw>sonet</kw>
            <kw>pdh</kw>
        </keywords>
        <abstract><p>The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links.  The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs).  This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work.  This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-transport-lmp-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4394</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4395</doc-id>
        <title>Guidelines and Registration Procedures for New URI Schemes</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes.  It also updates the process and IANA registry for URI schemes.  It obsoletes both RFC 2717 and RFC 2718.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-hansen-2717bis-2718bis-uri-guidelines-06</draft>
        <obsoletes>
            <doc-id>RFC2717</doc-id>
            <doc-id>RFC2718</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7595</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4395</errata-url>
        <doi>10.17487/RFC4395</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4396</doc-id>
        <title>RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text</title>
        <author>
            <name>J. Rey</name>
        </author>
        <author>
            <name>Y. Matsui</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>3GPP</kw>
            <kw>3GPP timed text</kw>
            <kw>streaming</kw>
            <kw> real-time streaming</kw>
            <kw>titling</kw>
            <kw>decorated text</kw>
            <kw>scrolling text</kw>
            <kw>karaoke</kw>
            <kw>hyperlinked text</kw>
            <kw>highlighted text</kw>
            <kw>blinking text</kw>
            <kw>highlight color</kw>
            <kw>text delay</kw>
            <kw>text style</kw>
            <kw>text box</kw>
            <kw>text wrap</kw>
            <kw>text sample</kw>
            <kw>sample descriptions</kw>
            <kw>modifier boxes</kw>
            <kw>UTF-8</kw>
            <kw>UTF-16</kw>
        </keywords>
        <abstract><p>This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text.  3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file.  Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations.  In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-3gpp-timed-text-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4396</errata-url>
        <doi>10.17487/RFC4396</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4397</doc-id>
        <title>A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture</title>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).</p><p> This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.</p><p> It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ason-lexicography-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4397</errata-url>
        <doi>10.17487/RFC4397</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4398</doc-id>
        <title>Storing Certificates in the Domain Name System (DNS)</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SC-DNS</kw>
            <kw>cryptology</kw>
            <kw>authenticity</kw>
        </keywords>
        <abstract><p>Cryptographic public keys are frequently published, and their authenticity is 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]</p></abstract>
        <draft>draft-ietf-dnsext-rfc2538bis-09</draft>
        <obsoletes>
            <doc-id>RFC2538</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6944</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4398</errata-url>
        <doi>10.17487/RFC4398</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4399</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4400</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4401</doc-id>
        <title>A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>secure session layer</kw>
            <kw>message integrity check</kw>
            <kw>mic</kw>
        </keywords>
        <abstract><p>This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context.  The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-gssapi-prf-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC4401</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4402</doc-id>
        <title>A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-krb5-gssapi-prf-04</draft>
        <obsoleted-by>
            <doc-id>RFC7802</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4402</errata-url>
        <doi>10.17487/RFC4402</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4403</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)</title>
        <author>
            <name>B. Bergeson</name>
        </author>
        <author>
            <name>K. Boogert</name>
        </author>
        <author>
            <name>V. Nanjundaswamy</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>LDAPv3</kw>
        </keywords>
        <abstract><p>This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory.  It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-bergeson-uddi-ldap-schema-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4403</errata-url>
        <doi>10.17487/RFC4403</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4404</doc-id>
        <title>Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)</title>
        <author>
            <name>R. Natarajan</name>
        </author>
        <author>
            <name>A. Rijhsinghani</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>fcip-mgmt-mib</kw>
        </keywords>
        <abstract><p>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 Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-fcip-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4404</errata-url>
        <doi>10.17487/RFC4404</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4405</doc-id>
        <title>SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message</title>
        <author>
            <name>E. Allman</name>
        </author>
        <author>
            <name>H. Katz</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>spam</kw>
            <kw>spoofing</kw>
            <kw>phishing</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message.  The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream.  This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-katz-submitter-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4405</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4406</doc-id>
        <title>Sender ID: Authenticating E-Mail</title>
        <author>
            <name>J. Lyon</name>
        </author>
        <author>
            <name>M. Wong</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>simple mail transfer protocol</kw>
            <kw>spam</kw>
            <kw>spoofing</kw>
        </keywords>
        <abstract><p>Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner.  This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-lyon-senderid-core-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4406</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4407</doc-id>
        <title>Purported Responsible Address in E-Mail Messages</title>
        <author>
            <name>J. Lyon</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>pra</kw>
            <kw>purported responsible address</kw>
        </keywords>
        <abstract><p>This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered.  This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-lyon-senderid-pra-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4407</errata-url>
        <doi>10.17487/RFC4407</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4408</doc-id>
        <title>Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1</title>
        <author>
            <name>M. Wong</name>
        </author>
        <author>
            <name>W. Schlitt</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>spoofing</kw>
            <kw>spf</kw>
        </keywords>
        <abstract><p>E-mail on the Internet can be forged in a number of ways.  In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands.  This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-schlitt-spf-classic-02</draft>
        <obsoleted-by>
            <doc-id>RFC7208</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6652</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4408</errata-url>
        <doi>10.17487/RFC4408</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4409</doc-id>
        <title>Message Submission for Mail</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>smtp</kw>
            <kw>simle mail transfer protocol</kw>
            <kw>ua</kw>
            <kw>user agent</kw>
        </keywords>
        <abstract><p>This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.</p><p> Message relay and final delivery are unaffected, and continue to use SMTP over port 25.</p><p> When conforming to this document, message submission uses the protocol specified here, normally over port 587.</p><p> This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gellens-submit-bis-02</draft>
        <obsoletes>
            <doc-id>RFC2476</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6409</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4409</errata-url>
        <doi>10.17487/RFC4409</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4410</doc-id>
        <title>Selectively Reliable Multicast Protocol (SRMP)</title>
        <author>
            <name>M. Pullen</name>
        </author>
        <author>
            <name>F. Zhao</name>
        </author>
        <author>
            <name>D. Cohen</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>transport</kw>
            <kw>best-effort</kw>
            <kw>srt</kw>
            <kw>selectively reliable transport</kw>
        </keywords>
        <abstract><p>The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection.  SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery.  SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer.  Selection between reliable and best-effort messages is performed by the application.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-pullen-srmp-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4410</errata-url>
        <doi>10.17487/RFC4410</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4411</doc-id>
        <title>Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events</title>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Resource-Priority</kw>
            <kw>preempt</kw>
            <kw>preempted</kw>
            <kw>Q.850</kw>
            <kw>preconditions</kw>
        </keywords>
        <abstract><p>This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS).  This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-reason-header-for-preemption-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4412</doc-id>
        <title>Communications Resource Priority for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>RP</kw>
            <kw>RPH</kw>
            <kw>preferential</kw>
            <kw>preempt</kw>
            <kw>preempted</kw>
            <kw>preemption</kw>
            <kw>queue</kw>
            <kw>DSN</kw>
            <kw>DRSN</kw>
            <kw>WPS</kw>
            <kw>ETS</kw>
            <kw>Q.735</kw>
            <kw>Q735</kw>
            <kw>disaster</kw>
            <kw>I.255</kw>
            <kw>flash</kw>
            <kw>flash-override</kw>
        </keywords>
        <abstract><p>This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority".  The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies.  It does not directly influence the forwarding behavior of IP routers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-resource-priority-10</draft>
        <updated-by>
            <doc-id>RFC7134</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4412</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4413</doc-id>
        <title>TCP/IP Field Behavior</title>
        <author>
            <name>M. West</name>
        </author>
        <author>
            <name>S. McCann</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>header compression</kw>
        </keywords>
        <abstract><p>This memo describes TCP/IP field behavior in the context of header compression.  Header compression is possible because most header fields do not vary randomly from packet to packet.  Many of the fields exhibit static behavior or change in a more or less predictable way.  When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail.  An example of this analysis can be seen in RFC 3095.  This memo performs a similar role for the compression of TCP/IP headers.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rohc-tcp-field-behavior-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4413</errata-url>
        <doi>10.17487/RFC4413</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4414</doc-id>
        <title>An ENUM Registry Type for the Internet Registry Information Service (IRIS)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <abstract><p>This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM 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 ENUM registries. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-iris-ereg-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4415</doc-id>
        <title>IANA Registration for Enumservice Voice</title>
        <author>
            <name>R. Brandner</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <author>
            <name>R. Stastny</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>uri</kw>
            <kw>voice call</kw>
            <kw>audio call</kw>
        </keywords>
        <abstract><p>This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761.  This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-voice-01</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4415</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4416</doc-id>
        <title>Goals for Internet Messaging to Support Diverse Service Environments</title>
        <author>
            <name>J. Wong</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>protocol extensions</kw>
            <kw>messaging</kw>
            <kw>wireless</kw>
            <kw>handheld</kw>
            <kw>telephone user interface</kw>
            <kw>multi-modal</kw>
            <kw>LEMONADE</kw>
            <kw>extension principles</kw>
            <kw>history</kw>
            <kw>background</kw>
            <kw>motivation</kw>
            <kw>cellular</kw>
            <kw>interworking</kw>
            <kw>constraints</kw>
            <kw>TUI</kw>
            <kw>WUI</kw>
            <kw>client</kw>
            <kw>MMS</kw>
        </keywords>
        <abstract><p>This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.</p><p> The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.</p><p> The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.</p><p> The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-lemonade-goals-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC4416</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4417</doc-id>
        <title>Report of the 2004 IAB Messaging Workshop</title>
        <author>
            <name>P. Resnick</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Saint-Andre</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>internet messaging</kw>
        </keywords>
        <abstract><p>This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging.  The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.  The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done.  This report summarizes the discussions and conclusions of the workshop and of the IAB.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-messaging-report-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4418</doc-id>
        <title>UMAC: Message Authentication Code using Universal Hashing</title>
        <author>
            <name>T. Krovetz</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.</p><p> To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-krovetz-umac-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4418</errata-url>
        <doi>10.17487/RFC4418</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4419</doc-id>
        <title>Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol</title>
        <author>
            <name>M. Friedl</name>
        </author>
        <author>
            <name>N. Provos</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This memo describes a new key exchange method for the Secure Shell (SSH) protocol.  It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client.  The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-dh-group-exchange-05</draft>
        <updated-by>
            <doc-id>RFC8270</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4419</errata-url>
        <doi>10.17487/RFC4419</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4420</doc-id>
        <title>Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>J.-P. Vasseur</name>
        </author>
        <author>
            <name>A. Ayyangar</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SESSION_ATTRIBUTE</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.</p><p> This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.</p><p> The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-rsvpte-attributes-05</draft>
        <obsoleted-by>
            <doc-id>RFC5420</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4420</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4421</doc-id>
        <title>RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>realtime transport protocol</kw>
            <kw>video stream</kw>
        </keywords>
        <abstract><p>The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP.  This memo extends the format to support additional colour sampling modes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-uncomp-video-ext-01</draft>
        <updates>
            <doc-id>RFC4175</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4421</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4422</doc-id>
        <title>Simple Authentication and Security Layer (SASL)</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>SASL</kw>
            <kw>encryption</kw>
            <kw>protocol specific</kw>
        </keywords>
        <abstract><p>The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.</p><p> This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.</p><p> This document obsoletes RFC 2222. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sasl-rfc2222bis-15</draft>
        <obsoletes>
            <doc-id>RFC2222</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <doi>10.17487/RFC4422</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4423</doc-id>
        <title>Host Identity Protocol (HIP) Architecture</title>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>P. Nikander</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers.  Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them.  The roles of this new namespace in the protocols are defined.  The memo describes the thinking of the authors as of Fall 2003.  The architecture may have evolved since.  This document represents one stable point in that evolution of understanding.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-arch-03</draft>
        <obsoleted-by>
            <doc-id>RFC9063</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4423</errata-url>
        <doi>10.17487/RFC4423</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4424</doc-id>
        <title>Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec</title>
        <author>
            <name>S. Ahmadi</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>speech codec</kw>
            <kw>variable-rate multicode wideband speech codec</kw>
        </keywords>
        <abstract><p>This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e., VMR-WB mode 4). These updates do not affect the existing modes of VMR-WB already specified in RFC 4348.</p><p> The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-vmr-wb-extension-02</draft>
        <updates>
            <doc-id>RFC4348</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4425</doc-id>
        <title>RTP Payload Format for Video Codec 1 (VC-1)</title>
        <author>
            <name>A. Klemets</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>smpte 421m</kw>
            <kw>wmv</kw>
            <kw>wmv9</kw>
            <kw>vc-9</kw>
        </keywords>
        <abstract><p>This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.  SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-vc1-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4425</errata-url>
        <doi>10.17487/RFC4425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4426</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification</title>
        <author>
            <name>J. Lang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Rajagopalan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration).  Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-recovery-functional-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4427</doc-id>
        <title>Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)</title>
        <author>
            <name>E. Mannie</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration).  The terminology is independent of the underlying transport technologies covered by GMPLS.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-recovery-terminology-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4427</errata-url>
        <doi>10.17487/RFC4427</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4428</doc-id>
        <title>Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)</title>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Mannie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group.  A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427.  This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-recovery-analysis-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4428</errata-url>
        <doi>10.17487/RFC4428</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4429</doc-id>
        <title>Optimistic Duplicate Address Detection (DAD) for IPv6</title>
        <author>
            <name>N. Moore</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>stateless address autoconfiguration</kw>
            <kw>neighbor discovery</kw>
        </keywords>
        <abstract><p>Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes.  The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-optimistic-dad-07</draft>
        <updated-by>
            <doc-id>RFC7527</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4429</errata-url>
        <doi>10.17487/RFC4429</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4430</doc-id>
        <title>Kerberized Internet Negotiation of Keys (KINK)</title>
        <author>
            <name>S. Sakane</name>
        </author>
        <author>
            <name>K. Kamada</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <author>
            <name>J. Vilhuber</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
        </keywords>
        <abstract><p>This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol.  KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system.  KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kink-kink-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kink</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4430</errata-url>
        <doi>10.17487/RFC4430</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4431</doc-id>
        <title>The DNSSEC Lookaside Validation (DLV) DNS Resource Record</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <author>
            <name>S. Weiler</name>
        </author>
        <date>
            <month>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>domain name space</kw>
        </keywords>
        <abstract><p>This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-andrews-dlv-dns-rr-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4432</doc-id>
        <title>RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol</title>
        <author>
            <name>B. Harris</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>rivest-sharmir-adleman</kw>
            <kw>public key encryption</kw>
        </keywords>
        <abstract><p>This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.  It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-harris-ssh-rsa-kex-06</draft>
        <updated-by>
            <doc-id>RFC9142</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4433</doc-id>
        <title>Mobile IPv4 Dynamic Home Agent (HA) Assignment</title>
        <author>
            <name>M. Kulkarni</name>
        </author>
        <author>
            <name>A. Patel</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract><p>Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN).  This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection.  The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-dynamic-assignment-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4433</errata-url>
        <doi>10.17487/RFC4433</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4434</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>February</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>security</kw>
            <kw>ipsec</kw>
            <kw>advanced encryption standard</kw>
            <kw>mac</kw>
            <kw>message authentication code</kw>
        </keywords>
        <abstract><p>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. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hoffman-rfc3664bis-05</draft>
        <obsoletes>
            <doc-id>RFC3664</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4434</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4435</doc-id>
        <title>A Framework for the Usage of Internet Media Guides (IMGs)</title>
        <author>
            <name>Y. Nomura</name>
        </author>
        <author>
            <name>R. Walsh</name>
        </author>
        <author>
            <name>J-P. Luoma</name>
        </author>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>session description protocol</kw>
            <kw>sdp</kw>
            <kw>sdpng</kw>
        </keywords>
        <abstract><p>This document defines a framework for the delivery of Internet Media Guides (IMGs).  An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format.  This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mmusic-img-framework-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4435</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4436</doc-id>
        <title>Detecting Network Attachment in IPv4 (DNAv4)</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Carlson</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment.  This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dna-ipv4-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4436</errata-url>
        <doi>10.17487/RFC4436</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4437</doc-id>
        <title>Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources</title>
        <author>
            <name>J. Whitehead</name>
        </author>
        <author>
            <name>G. Clemm</name>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>http</kw>
            <kw>hyper text transfer protocol</kw>
        </keywords>
        <abstract><p>This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code.  A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource.  This specification does not address remapping of trees of resources or regular expression based redirections.  There are no integrity guarantees associated with redirect reference resources.  Other mechanisms can also be used to achieve the same functionality as this specification.  This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-webdav-redirectref-protocol-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <doi>10.17487/RFC4437</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4438</doc-id>
        <title>Fibre-Channel Name Server MIB</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>V. Gaonkar</name>
        </author>
        <author>
            <name>H.K. Vivek</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-fc-name-server-mib</kw>
        </keywords>
        <abstract><p>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 Name Server function of a Fibre Channel network.  The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-nsm-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4438</errata-url>
        <doi>10.17487/RFC4438</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4439</doc-id>
        <title>Fibre Channel Fabric Address Manager MIB</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>V. Gaonkar</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>t11-tc-mib</kw>
            <kw>t11-fc-fabric-addr-mgr-mib</kw>
        </keywords>
        <abstract><p>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 a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-fam-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4439</errata-url>
        <doi>10.17487/RFC4439</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4440</doc-id>
        <title>IAB Thoughts on the Role of the Internet Research Task Force (IRTF)</title>
        <author>
            <name>S. Floyd</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Paxson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Falk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>internet architecture board</kw>
        </keywords>
        <abstract><p>This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF.  This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-irtf-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4440</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4441</doc-id>
        <title>The IEEE 802/IETF Relationship</title>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>aaa</kw>
            <kw>simple network management protocol</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications.  This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-ieee-802-rel-05</draft>
        <obsoleted-by>
            <doc-id>RFC7241</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4441</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4442</doc-id>
        <title>Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)</title>
        <author>
            <name>S. Fries</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>mikey</kw>
            <kw>multimedia internet keying protocol</kw>
        </keywords>
        <abstract><p>TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.</p><p> This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-bootstrapping-tesla-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4442</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4443</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>
        <author>
            <name>M. Gupta</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol).  ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipngwg-icmp-v3-07</draft>
        <obsoletes>
            <doc-id>RFC2463</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2780</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4884</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0089</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4443</errata-url>
        <doi>10.17487/RFC4443</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4444</doc-id>
        <title>Management Information Base for Intermediate System to Intermediate System (IS-IS)</title>
        <author>
            <name>J. Parker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>103</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>routing protocol</kw>
            <kw>isis-mib</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-wg-mib-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4444</errata-url>
        <doi>10.17487/RFC4444</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4445</doc-id>
        <title>A Proposed Media Delivery Index (MDI)</title>
        <author>
            <name>J. Welch</name>
        </author>
        <author>
            <name>J. Clark</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss.  It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow.  For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-welch-mdi-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4445</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4446</doc-id>
        <title>IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)</title>
        <author>
            <name>L. Martini</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group.  Detailed IANA allocation instructions are also included in this document.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-pwe3-iana-allocation-15</draft>
        <is-also>
            <doc-id>BCP0116</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4446</errata-url>
        <doi>10.17487/RFC4446</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4447</doc-id>
        <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>N. El-Aawar</name>
        </author>
        <author>
            <name>T. Smith</name>
        </author>
        <author>
            <name>G. Heron</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>multiprotocol label switching protocol</kw>
            <kw>pdu</kw>
            <kw>protocol data units</kw>
        </keywords>
        <abstract><p>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires".  It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network.  This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).  Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-control-protocol-17</draft>
        <obsoleted-by>
            <doc-id>RFC8077</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6723</doc-id>
            <doc-id>RFC6870</doc-id>
            <doc-id>RFC7358</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4447</errata-url>
        <doi>10.17487/RFC4447</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4448</doc-id>
        <title>Encapsulation Methods for Transport of Ethernet over MPLS Networks</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>N. El-Aawar</name>
        </author>
        <author>
            <name>G. Heron</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>pw</kw>
            <kw>pseudowire</kw>
            <kw>pdu</kw>
            <kw>protocol data units</kw>
        </keywords>
        <abstract><p>An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network.  This enables service providers to offer "emulated" Ethernet services over existing MPLS networks.  This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire.  It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-ethernet-encap-11</draft>
        <updated-by>
            <doc-id>RFC5462</doc-id>
            <doc-id>RFC8469</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4448</errata-url>
        <doi>10.17487/RFC4448</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4449</doc-id>
        <title>Securing Mobile IPv6 Route Optimization Using a Static Shared Key</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>mobile node</kw>
            <kw>correspondent node</kw>
            <kw>binding management key</kw>
            <kw>binding updates</kw>
        </keywords>
        <abstract><p>A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-precfgkbm-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4449</errata-url>
        <doi>10.17487/RFC4449</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4450</doc-id>
        <title>Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today.  The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-newtrk-decruft-experiment-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>newtrk</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4450</errata-url>
        <doi>10.17487/RFC4450</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4451</doc-id>
        <title>BGP MULTI_EXIT_DISC (MED) Considerations</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>V. Gill</name>
        </author>
        <date>
            <month>March</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.</p><p> This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-grow-bgp-med-considerations-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC4451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4452</doc-id>
        <title>The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces</title>
        <author>
            <name>H. Van de Sompel</name>
        </author>
        <author>
            <name>T. Hammond</name>
        </author>
        <author>
            <name>E. Neylon</name>
        </author>
        <author>
            <name>S. Weibel</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
        </keywords>
        <abstract><p>This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces.  Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-vandesompel-info-uri-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4452</errata-url>
        <doi>10.17487/RFC4452</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4453</doc-id>
        <title>Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>G. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Willis</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>sip extensions</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence.  In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient.  Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks.  This document identifies a set of requirements for extensions to SIP that add consent-based communications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-consent-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4453</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4454</doc-id>
        <title>Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)</title>
        <author>
            <name>S. Singh</name>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>extensible tunneling protocol</kw>
        </keywords>
        <abstract><p>The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks.  This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over an IP network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-pwe3-atm-04</draft>
        <updated-by>
            <doc-id>RFC5641</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC4454</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4455</doc-id>
        <title>Definition of Managed Objects for Small Computer System Interface (SCSI) Entities</title>
        <author>
            <name>M. Hallak-Stamler</name>
        </author>
        <author>
            <name>M. Bakke</name>
        </author>
        <author>
            <name>Y. Lederman</name>
        </author>
        <author>
            <name>M. Krueger</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>scsi-mib</kw>
        </keywords>
        <abstract><p>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 Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-scsi-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4455</errata-url>
        <doi>10.17487/RFC4455</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4456</doc-id>
        <title>BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BGP-RR</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
        </keywords>
        <abstract><p>The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.</p><p> This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).</p><p> This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-rfc2796bis-02</draft>
        <obsoletes>
            <doc-id>RFC2796</doc-id>
            <doc-id>RFC1966</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7606</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4456</errata-url>
        <doi>10.17487/RFC4456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4457</doc-id>
        <title>The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>G. Blanco</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>3gpp</kw>
            <kw>third generation partnership project</kw>
            <kw>3rd generation partnership project</kw>
            <kw>ims</kw>
            <kw>ip multimedia subsystem</kw>
        </keywords>
        <abstract><p>This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header).  This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-camarillo-sipping-user-database-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4457</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4458</doc-id>
        <title>Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <author>
            <name>J. Elwell</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>universal resource identifiers</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems.  This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-jennings-sip-voicemail-uri-06</draft>
        <updated-by>
            <doc-id>RFC8119</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4458</errata-url>
        <doi>10.17487/RFC4458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4459</doc-id>
        <title>MTU and Fragmentation Issues with In-the-Network Tunneling</title>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided.  This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-savola-mtufrag-network-tunneling-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4460</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Specification Errata and Issues</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>I. Arias-Rodriguez</name>
        </author>
        <author>
            <name>K. Poon</name>
        </author>
        <author>
            <name>A. Caro</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>109</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>transport</kw>
            <kw>packet</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes.  This document provides deltas to RFC 2960 and is organized in a time-based way.  The issues are listed in the order they were brought up.  Because some text is changed several times, the last delta in the text is the one that should be applied.  In addition to the delta, a description of the problem and the details of the solution are also provided.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-sctpimpguide-16</draft>
        <obsoleted-by>
            <doc-id>RFC9260</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4460</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4461</doc-id>
        <title>Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>S. Yasukawa</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>p2mp</kw>
            <kw>multiprotocol label switching</kw>
        </keywords>
        <abstract><p>This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).</p><p> There is no intent to specify solution-specific details or application-specific requirements in this document.</p><p> The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-p2mp-sig-requirement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4461</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4462</doc-id>
        <title>Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol</title>
        <author>
            <name>J. Hutzelman</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>J. Galbraith</name>
        </author>
        <author>
            <name>V. Welch</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</p><p> The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.</p><p> This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.</p><p> This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-gsskeyex-10</draft>
        <updated-by>
            <doc-id>RFC8732</doc-id>
            <doc-id>RFC9142</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4462</errata-url>
        <doi>10.17487/RFC4462</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4463</doc-id>
        <title>A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks</title>
        <author>
            <name>S. Shanmugham</name>
        </author>
        <author>
            <name>P. Monaco</name>
        </author>
        <author>
            <name>B. Eberman</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <abstract><p>This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.</p><p> MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shanmugham-mrcp-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4463</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4464</doc-id>
        <title>Signaling Compression (SigComp) Users' Guide</title>
        <author>
            <name>A. Surtees</name>
        </author>
        <author>
            <name>M. West</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>This document provides an informational guide for users of the Signaling Compression (SigComp) protocol.  The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rohc-sigcomp-user-guide-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4464</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4465</doc-id>
        <title>Signaling Compression (SigComp) Torture Tests</title>
        <author>
            <name>A. Surtees</name>
        </author>
        <author>
            <name>M. West</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>SigComp Universal Decompressor Virtual Machine</kw>
        </keywords>
        <abstract><p>This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol.  The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms.  Tests are also provided for other SigComp entities such as the dispatcher and the state handler.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rohc-sigcomp-torture-tests-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4465</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4466</doc-id>
        <title>Collected Extensions to IMAP4 ABNF</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.</p><p> This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.</p><p> This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-imap-ext-abnf-08</draft>
        <updates>
            <doc-id>RFC2088</doc-id>
            <doc-id>RFC2342</doc-id>
            <doc-id>RFC3501</doc-id>
            <doc-id>RFC3502</doc-id>
            <doc-id>RFC3516</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6237</doc-id>
            <doc-id>RFC7377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4466</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4467</doc-id>
        <title>Internet Message Access Protocol (IMAP) - URLAUTH Extension</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>imap url</kw>
            <kw>imapurl</kw>
        </keywords>
        <abstract><p>This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.</p><p> An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-urlauth-08</draft>
        <updated-by>
            <doc-id>RFC5092</doc-id>
            <doc-id>RFC5550</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC4467</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4468</doc-id>
        <title>Message Submission BURL Extension</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>URLAUTH</kw>
            <kw>IMAP</kw>
            <kw>IMAPURL</kw>
            <kw>Forward-without-download</kw>
            <kw>mobile-client</kw>
            <kw>lemonade</kw>
        </keywords>
        <abstract><p>The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery.  This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server.  This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-burl-04</draft>
        <updates>
            <doc-id>RFC3463</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5248</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4468</errata-url>
        <doi>10.17487/RFC4468</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4469</doc-id>
        <title>Internet Message Access Protocol (IMAP) CATENATE Extension</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>append</kw>
        </keywords>
        <abstract><p>The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server.  Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-catenate-05</draft>
        <updates>
            <doc-id>RFC3501</doc-id>
            <doc-id>RFC3502</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5550</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4469</errata-url>
        <doi>10.17487/RFC4469</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4470</doc-id>
        <title>Minimally Covering NSEC Records and DNSSEC On-line Signing</title>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>J. Ihren</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>dns security</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034.  By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-online-signing-02</draft>
        <updates>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC4034</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4470</errata-url>
        <doi>10.17487/RFC4470</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4471</doc-id>
        <title>Derivation of DNS Name Predecessor and Successor</title>
        <author>
            <name>G. Sisson</name>
        </author>
        <author>
            <name>B. Laurie</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>domain namespace</kw>
            <kw>dynamic nsec</kw>
            <kw>dnssec</kw>
        </keywords>
        <abstract><p>This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name.  These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsext-dns-name-p-s-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC4471</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4472</doc-id>
        <title>Operational Considerations and Issues with IPv6 DNS</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>J. Ihren</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues.  This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsop-ipv6-dns-issues-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC4472</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4473</doc-id>
        <title>Requirements for Internet Media Guides (IMGs)</title>
        <author>
            <name>Y. Nomura</name>
        </author>
        <author>
            <name>R. Walsh</name>
        </author>
        <author>
            <name>J-P. Luoma</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>media-on-deman</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications.  These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mmusic-img-req-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4473</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4474</doc-id>
        <title>Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>security</kw>
            <kw>identity</kw>
            <kw>identity-info</kw>
        </keywords>
        <abstract><p>The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP messages.  It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-identity-06</draft>
        <obsoleted-by>
            <doc-id>RFC8224</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4474</errata-url>
        <doi>10.17487/RFC4474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4475</doc-id>
        <title>Session Initiation Protocol (SIP) Torture Test Messages</title>
        <author>
            <name>R. Sparks</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Hawrylyshen</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-torture-tests-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4475</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4476</doc-id>
        <title>Attribute Certificate (AC) Policies Extension</title>
        <author>
            <name>C. Francis</name>
        </author>
        <author>
            <name>D. Pinkas</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>acp</kw>
            <kw>attribute certificate policies</kw>
        </keywords>
        <abstract><p>This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC).  The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-acpolicies-extn-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4476</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4477</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues</title>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>C. Strauf</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>A node may have support for communications using IPv4 and/or IPv6 protocols.  Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP).  The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6.  This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers.  The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dhc-dual-stack-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4477</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4478</doc-id>
        <title>Repeated Authentication in Internet Key Exchange (IKEv2) Protocol</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>lifetime</kw>
        </keywords>
        <abstract><p>This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2].  With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically.  The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer.  This document describes a mechanism to perform this function.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-nir-ikev2-auth-lt-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4478</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4479</doc-id>
        <title>A Data Model for Presence</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>simple</kw>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
        </keywords>
        <abstract><p>This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents.  The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-presence-data-model-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4479</errata-url>
        <doi>10.17487/RFC4479</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4480</doc-id>
        <title>RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.</p><p> This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.</p><p> These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-rpid-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4480</errata-url>
        <doi>10.17487/RFC4480</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4481</doc-id>
        <title>Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity.  This document extends PIDF, adding a timed status extension (&lt;timed-status&gt; element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-future-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC4481</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4482</doc-id>
        <title>CIPID: Contact Information for the Presence Information Data Format</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>pidf</kw>
        </keywords>
        <abstract><p>The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity.  The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-cipid-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC4482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4483</doc-id>
        <title>A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages</title>
        <author>
            <name>E. Burger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>universal resource locator</kw>
            <kw>mime</kw>
            <kw>external-body access-type</kw>
        </keywords>
        <abstract><p>This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP).  These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-content-indirect-mech-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4483</errata-url>
        <doi>10.17487/RFC4483</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4484</doc-id>
        <title>Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>D. Sicker</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>policy decision</kw>
        </keywords>
        <abstract><p>This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP).  While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session.  This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-trait-authz-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4484</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4485</doc-id>
        <title>Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>interactive communication</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet.  Part of this flexibility is the ease with which it can be extended.  In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions.  This document outlines a set of such guidelines for authors of SIP extensions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sip-guidelines-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4485</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4486</doc-id>
        <title>Subcodes for BGP Cease Notification Message</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>V. Gillet</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>bgp peers</kw>
        </keywords>
        <abstract><p>This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-cease-subcode-07</draft>
        <updated-by>
            <doc-id>RFC8203</doc-id>
            <doc-id>RFC9003</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC4486</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4487</doc-id>
        <title>Mobile IPv6 and Firewalls: Problem Statement</title>
        <author>
            <name>F. Le</name>
        </author>
        <author>
            <name>S. Faccin</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>3g</kw>
            <kw>mobile networks</kw>
        </keywords>
        <abstract><p>This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.</p><p> The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-firewalls-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC4487</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4488</doc-id>
        <title>Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription</title>
        <author>
            <name>O. Levin</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER.  These notifications are not needed in all cases.  This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-refer-with-norefersub-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4488</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4489</doc-id>
        <title>A Method for Generating Link-Scoped IPv6 Multicast Addresses</title>
        <author>
            <name>J-S. Park</name>
        </author>
        <author>
            <name>M-K. Shin</name>
        </author>
        <author>
            <name>H-J. Kim</name>
        </author>
        <date>
            <month>April</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>iid</kw>
            <kw>interface identifiers</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the multicast addressing architecture of the IPv6 protocol.  The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses.  When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined.  After that, each node can generate its unique multicast addresses automatically without conflicts.  The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses.  This memo updates RFC 3306. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-link-scoped-mcast-09</draft>
        <updates>
            <doc-id>RFC3306</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4489</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4490</doc-id>
        <title>Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>S. Leontiev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Chudov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>CPCMS</kw>
            <kw>S/MIME</kw>
            <kw>PKIX</kw>
            <kw>X.509</kw>
            <kw>certificate</kw>
            <kw>CRL</kw>
            <kw>revocation</kw>
            <kw>public-key</kw>
            <kw>one-way</kw>
            <kw>hash</kw>
            <kw>block</kw>
            <kw>cipher</kw>
            <kw>encryption</kw>
            <kw>decryption</kw>
            <kw>MAC</kw>
            <kw>HMAC</kw>
            <kw>PRF</kw>
            <kw>wrap</kw>
            <kw>unwrap</kw>
            <kw>UKM</kw>
            <kw>KEK</kw>
            <kw>key</kw>
            <kw>Diffie-Hellman</kw>
            <kw>agreement</kw>
            <kw>transport</kw>
            <kw>parameter</kw>
            <kw>derivation</kw>
            <kw>digest</kw>
            <kw>CBC</kw>
            <kw>counter</kw>
            <kw>mode</kw>
            <kw>digital</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS).  The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-gost-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4490</errata-url>
        <doi>10.17487/RFC4490</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4491</doc-id>
        <title>Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
        <author>
            <name>S. Leontiev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Shefanovski</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>X.509</kw>
            <kw>CPPK</kw>
            <kw>public-key</kw>
            <kw>one-way hash function</kw>
            <kw>block cipher</kw>
            <kw>encryption</kw>
            <kw>decryption</kw>
            <kw>key derivation</kw>
            <kw>parameter</kw>
            <kw>message digest</kw>
            <kw>digital signature</kw>
            <kw>34.310</kw>
            <kw>34.311</kw>
            <kw>34.310-95</kw>
            <kw>34.310-2004</kw>
            <kw>34.311-95</kw>
        </keywords>
        <abstract><p>This document supplements RFC 3279.  It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-gost-cppk-05</draft>
        <updates>
            <doc-id>RFC3279</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4491</errata-url>
        <doi>10.17487/RFC4491</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4492</doc-id>
        <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)</title>
        <author>
            <name>S. Blake-Wilson</name>
        </author>
        <author>
            <name>N. Bolyard</name>
        </author>
        <author>
            <name>V. Gupta</name>
        </author>
        <author>
            <name>C. Hawk</name>
        </author>
        <author>
            <name>B. Moeller</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>ecdh</kw>
            <kw>elliptic curve diffie-hellman</kw>
            <kw>elliptic curve digital signature algorithm</kw>
            <kw>ecdsa</kw>
        </keywords>
        <abstract><p>This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol.  In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tls-ecc-12</draft>
        <obsoleted-by>
            <doc-id>RFC8422</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC7027</doc-id>
            <doc-id>RFC7919</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4492</errata-url>
        <doi>10.17487/RFC4492</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4493</doc-id>
        <title>The AES-CMAC Algorithm</title>
        <author>
            <name>JH. Song</name>
        </author>
        <author>
            <name>R. Poovendran</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>T. Iwata</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>cipher-based message authentication code</kw>
            <kw>omac1</kw>
            <kw>one-key cbc mac1</kw>
            <kw>advanced encryption algorithm</kw>
        </keywords>
        <abstract><p>The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa.  This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES).  This new authentication algorithm is named AES-CMAC.  The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-songlee-aes-cmac-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4493</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4494</doc-id>
        <title>The AES-CMAC-96 Algorithm and Its Use with IPsec</title>
        <author>
            <name>JH. Song</name>
        </author>
        <author>
            <name>R. Poovendran</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>cipher-basd message authentication code</kw>
            <kw>one-key cbc-mac1</kw>
            <kw>omac1</kw>
            <kw>xcbc</kw>
            <kw>extended cipher block chaining</kw>
            <kw>advanced encryption standard</kw>
        </keywords>
        <abstract><p>The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa.  OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC).  This memo specifies the use of CMAC mode as an authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols.  This new algorithm is named AES-CMAC-96. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-songlee-aes-cmac-96-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4494</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4495</doc-id>
        <title>A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow</title>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>S. Dhesikan</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>rsvpv1</kw>
        </keywords>
        <abstract><p>This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation.  This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels.  This specification is an extension of RFC 2205. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-bw-reduction-02</draft>
        <updates>
            <doc-id>RFC2205</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4495</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4496</doc-id>
        <title>Open Pluggable Edge Services (OPES) SMTP Use Cases</title>
        <author>
            <name>M. Stecher</name>
        </author>
        <author>
            <name>A. Barbir</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The Open Pluggable Edge Services (OPES) framework is application agnostic.  Application-specific adaptations extend that framework.  This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-opes-smtp-use-cases-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC4496</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4497</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and QSIG</title>
        <author>
            <name>J. Elwell</name>
        </author>
        <author>
            <name>F. Derks</name>
        </author>
        <author>
            <name>P. Mourot</name>
        </author>
        <author>
            <name>O. Rousseau</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>telecommunication networks</kw>
            <kw>enterprise networks</kw>
            <kw>signalling</kw>
        </keywords>
        <abstract><p>This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks).  SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include, in particular, telephone calls.  QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs).  QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-sipping-qsig2sip-04</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0117</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4497</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4498</doc-id>
        <title>The Managed Object Aggregation MIB</title>
        <author>
            <name>G. Keeni</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>aggregate mib</kw>
            <kw>time aggregate mib</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community.  In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-glenn-mo-aggr-mib-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4498</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4499</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4500</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4501</doc-id>
        <title>Domain Name System Uniform Resource Identifiers</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>uri</kw>
        </keywords>
        <abstract><p>This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-josefsson-dns-url-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4501</errata-url>
        <doi>10.17487/RFC4501</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4502</doc-id>
        <title>Remote Network Monitoring Management Information Base Version 2</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>142</page-count>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>RMON</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>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 remote network monitoring devices.</p><p> This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmonmib-rmon2-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2021</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3273</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4502</errata-url>
        <doi>10.17487/RFC4502</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4503</doc-id>
        <title>A Description of the Rabbit Stream Cipher Algorithm</title>
        <author>
            <name>M. Boesgaard</name>
        </author>
        <author>
            <name>M. Vesterager</name>
        </author>
        <author>
            <name>E. Zenner</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>iv</kw>
            <kw>initialization vector</kw>
            <kw>encryption algorithm</kw>
        </keywords>
        <abstract><p>This document describes the encryption algorithm Rabbit.  It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV).  The method was published in 2003 and has been subject to public security and performance revision.  Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-zenner-rabbit-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4503</errata-url>
        <doi>10.17487/RFC4503</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4504</doc-id>
        <title>SIP Telephony Device Requirements and Configuration</title>
        <author>
            <name>H. Sinnreich</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Lass</name>
        </author>
        <author>
            <name>C. Stredicke</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>session initiation protocol</kw>
            <kw>pc</kw>
            <kw>pda</kw>
            <kw>analog</kw>
        </keywords>
        <abstract><p>This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.</p><p> We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-sinnreich-sipdev-req-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4504</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4505</doc-id>
        <title>Anonymous Simple Authentication and Security Layer (SASL) Mechanism</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SASL-ANON</kw>
            <kw>Simple</kw>
            <kw>Authentication</kw>
            <kw>Security</kw>
            <kw>Layer</kw>
        </keywords>
        <abstract><p>On the Internet, it is common practice to permit anonymous access to various services.  Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password.  As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sasl-anon-05</draft>
        <obsoletes>
            <doc-id>RFC2245</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <doi>10.17487/RFC4505</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4506</doc-id>
        <title>XDR: External Data Representation Standard</title>
        <author>
            <name>M. Eisler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>XDR</kw>
            <kw>rpc</kw>
            <kw>onc</kw>
            <kw>open network computing</kw>
        </keywords>
        <abstract><p>This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted.  This document obsoletes RFC 1832. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-rfc1832bis-06</draft>
        <obsoletes>
            <doc-id>RFC1832</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0067</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4506</errata-url>
        <doi>10.17487/RFC4506</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4507</doc-id>
        <title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>H. Zhou</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \%per-client session state.  The TLS server encapsulates the session state into a ticket and forwards it to the client.  The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-salowey-tls-ticket-07</draft>
        <obsoleted-by>
            <doc-id>RFC5077</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4507</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4508</doc-id>
        <title>Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method</title>
        <author>
            <name>O. Levin</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>caller preferences</kw>
        </keywords>
        <abstract><p>The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request.  The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request.  This document extends the REFER method to use the mechanism of RFC 3840.  By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-refer-feature-param-01</draft>
        <updated-by>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4508</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4509</doc-id>
        <title>Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>dns</kw>
            <kw>dnskey</kw>
        </keywords>
        <abstract><p>This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs).  DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-ds-sha256-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4509</errata-url>
        <doi>10.17487/RFC4509</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4510</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>LDAPV3</kw>
            <kw>LDAV3</kw>
            <kw>x.500</kw>
            <kw>LDAP3-ATD</kw>
            <kw>syntax</kw>
            <kw>LDAP3-UTF8</kw>
            <kw>x.500</kw>
            <kw>ASN.1</kw>
            <kw>string format</kw>
            <kw>STR-LDAP</kw>
            <kw>LDAP-URL</kw>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>Universal Resource Locator</kw>
        </keywords>
        <abstract><p>The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models.  This document provides a road map of the LDAP Technical Specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-roadmap-08</draft>
        <obsoletes>
            <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>
            <doc-id>RFC3377</doc-id>
            <doc-id>RFC3771</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4510</errata-url>
        <doi>10.17487/RFC4510</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4511</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): The Protocol</title>
        <author>
            <name>J. Sermersheim</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>TLS</kw>
            <kw>LDAPv3</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
        </keywords>
        <abstract><p>This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP).  LDAP provides access to distributed directory services that act in accordance with X.500 data and service models.  These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-protocol-32</draft>
        <obsoletes>
            <doc-id>RFC2251</doc-id>
            <doc-id>RFC2830</doc-id>
            <doc-id>RFC3771</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4511</errata-url>
        <doi>10.17487/RFC4511</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4512</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Directory Information Models</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
            <kw>LDAPv3</kw>
            <kw>LDAP3-ATD</kw>
            <kw>syntax</kw>
            <kw>elective extensions</kw>
            <kw>mechanisms</kw>
        </keywords>
        <abstract><p>The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models.  This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-models-14</draft>
        <obsoletes>
            <doc-id>RFC2251</doc-id>
            <doc-id>RFC2252</doc-id>
            <doc-id>RFC2256</doc-id>
            <doc-id>RFC3674</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4512</errata-url>
        <doi>10.17487/RFC4512</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4513</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms</title>
        <author>
            <name>R. Harrison</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>LDAP</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.</p><p> This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.</p><p> This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.</p><p> This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-authmeth-19</draft>
        <obsoletes>
            <doc-id>RFC2251</doc-id>
            <doc-id>RFC2829</doc-id>
            <doc-id>RFC2830</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4513</errata-url>
        <doi>10.17487/RFC4513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4514</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>LDAP3-UTF8</kw>
            <kw>LDAPv3</kw>
            <kw>x.500</kw>
            <kw>ASN.1</kw>
            <kw>string</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory.  This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names.  The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-dn-16</draft>
        <obsoletes>
            <doc-id>RFC2253</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4514</errata-url>
        <doi>10.17487/RFC4514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4515</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters</title>
        <author>
            <name>M. Smith</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>STR-LDAP</kw>
            <kw>STRLDAP</kw>
            <kw>LDAPv3</kw>
            <kw>X.500</kw>
            <kw>BER</kw>
            <kw>ASN.1</kw>
        </keywords>
        <abstract><p>Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network.  This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-filter-09</draft>
        <obsoletes>
            <doc-id>RFC2254</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4515</errata-url>
        <doi>10.17487/RFC4515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4516</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator</title>
        <author>
            <name>M. Smith</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>LDAP-URL</kw>
            <kw>LDAPURL</kw>
            <kw>LDAP search</kw>
            <kw>URL</kw>
            <kw>URI</kw>
            <kw>LDAPv3</kw>
        </keywords>
        <abstract><p>This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL).  An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-url-09</draft>
        <obsoletes>
            <doc-id>RFC2255</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4516</errata-url>
        <doi>10.17487/RFC4516</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4517</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules</title>
        <author>
            <name>S. Legg</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>LDAP3-ATD</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values.  The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules.  Matching rules specify an argument, an assertion value, which also has a defined syntax.  This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-syntaxes-11</draft>
        <obsoletes>
            <doc-id>RFC2252</doc-id>
            <doc-id>RFC2256</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3698</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4517</errata-url>
        <doi>10.17487/RFC4517</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4518</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed.  This led to a number of usability and interoperability problems.  This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-strprep-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4518</errata-url>
        <doi>10.17487/RFC4518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4519</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Schema for User Applications</title>
        <author>
            <name>A. Sciberras</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Lightweight Directory Access Protocol</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract><p>This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification.  It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages.  These objects are widely used as a basis for the schema in many LDAP directories.  This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ldapbis-user-schema-11</draft>
        <obsoletes>
            <doc-id>RFC2256</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2247</doc-id>
            <doc-id>RFC2798</doc-id>
            <doc-id>RFC2377</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4519</errata-url>
        <doi>10.17487/RFC4519</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4520</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>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP).  The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ldapbis-bcp64-07</draft>
        <obsoletes>
            <doc-id>RFC3383</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0064</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ldapbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4520</errata-url>
        <doi>10.17487/RFC4520</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4521</doc-id>
        <title>Considerations for Lightweight Directory Access Protocol (LDAP) Extensions</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>The Lightweight Directory Access Protocol (LDAP) is extensible.  It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas.  This document discusses considerations for designers of LDAP extensions.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-zeilenga-ldap-ext-10</draft>
        <is-also>
            <doc-id>BCP0118</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4521</errata-url>
        <doi>10.17487/RFC4521</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4522</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ber</kw>
            <kw>ldap-specific encoding</kw>
        </keywords>
        <abstract><p>Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type).  A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations.  This representation is referred to as the LDAP\-specific encoding to distinguish it from other methods of encoding attribute values.  This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-legg-ldap-binary-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4522</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4523</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>LDAP3-ATD</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
            <kw>syntax</kw>
            <kw>pkix</kw>
        </keywords>
        <abstract><p>This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP).  The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-x509-02</draft>
        <obsoletes>
            <doc-id>RFC2252</doc-id>
            <doc-id>RFC2256</doc-id>
            <doc-id>RFC2587</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4523</errata-url>
        <doi>10.17487/RFC4523</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4524</doc-id>
        <title>COSINE LDAP/X.500 Schema</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Naming</kw>
        </keywords>
        <abstract><p>This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects.</p><p> This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-cosine-02</draft>
        <obsoletes>
            <doc-id>RFC1274</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2247</doc-id>
            <doc-id>RFC2798</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4524</errata-url>
        <doi>10.17487/RFC4524</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4525</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>pre-read</kw>
            <kw>post-read</kw>
            <kw>control extension</kw>
        </keywords>
        <abstract><p>This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability.  This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-zeilenga-ldap-incr-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4525</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4526</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>x.500</kw>
            <kw>string representation</kw>
        </keywords>
        <abstract><p>This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems.  The document also extends the String Representation of LDAP Search Filters to support these filters. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-t-f-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4526</errata-url>
        <doi>10.17487/RFC4526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4527</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Read Entry Controls</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation.  The client may request to read the entry before and/or after the modifications are applied.  These reads are done as an atomic part of the update operation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-readentry-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4527</errata-url>
        <doi>10.17487/RFC4527</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4528</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Assertion Control</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>test and set</kw>
            <kw>test and clear</kw>
        </keywords>
        <abstract><p>This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true.  It can be used to construct "test and set", "test and clear", and other conditional operations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-assert-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4528</errata-url>
        <doi>10.17487/RFC4528</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4529</doc-id>
        <title>Requesting Attributes by Object Class in the Lightweight Directory Access Protocol</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description.  This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-zeilenga-ldap-adlist-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4529</errata-url>
        <doi>10.17487/RFC4529</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4530</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>x.500</kw>
            <kw>universally unique identifier</kw>
        </keywords>
        <abstract><p>This document describes the LDAP/X.500 \'entryUUID' operational attribute and associated matching rules and syntax.  The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object.  Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-uuid-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4530</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4531</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Turn Operation</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>turn request</kw>
            <kw>turn response</kw>
        </keywords>
        <abstract><p>This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-zeilenga-ldap-turn-03</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4531</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4532</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>authorization identity</kw>
        </keywords>
        <abstract><p>This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity.  This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-authzid-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4532</errata-url>
        <doi>10.17487/RFC4532</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4533</doc-id>
        <title>The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <author>
            <name>J.H. Choi</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>dit</kw>
            <kw>directory information tree</kw>
        </keywords>
        <abstract><p>This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation.  The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT).  It supports both polling for changes and listening for changes.  The operation is defined as an extension of the LDAP Search Operation.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-zeilenga-ldup-sync-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4533</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4534</doc-id>
        <title>Group Security Policy Token v1</title>
        <author>
            <name>A. Colegrove</name>
        </author>
        <author>
            <name>H. Harney</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>cryptographic group</kw>
        </keywords>
        <abstract><p>The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group.  Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security.  This document specifies the structure of such a token. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-policy-token-sec-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4534</errata-url>
        <doi>10.17487/RFC4534</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4535</doc-id>
        <title>GSAKMP: Group Secure Association Key Management Protocol</title>
        <author>
            <name>H. Harney</name>
        </author>
        <author>
            <name>U. Meth</name>
        </author>
        <author>
            <name>A. Colegrove</name>
        </author>
        <author>
            <name>G. Gross</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>106</page-count>
        <keywords>
            <kw>security framework</kw>
            <kw>cryptographic network</kw>
        </keywords>
        <abstract><p>This document specifies the Group Secure Association Key Management Protocol (GSAKMP).  The GSAKMP provides a security framework for creating and managing cryptographic groups on a network.  It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group.  It also generates group keys. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-gsakmp-sec-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4535</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4536</doc-id>
        <title>The application/smil and application/smil+xml Media Types</title>
        <author>
            <name>P. Hoschka</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>synchronized multimedia integration language</kw>
        </keywords>
        <abstract><p>This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1).  SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hoschka-smil-media-type-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4536</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4537</doc-id>
        <title>Kerberos Cryptosystem Negotiation Extension</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zhu-kerb-enctype-nego-04</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC4537</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4538</doc-id>
        <title>Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>tdialog</kw>
        </keywords>
        <abstract><p>This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog.  This header field is used in requests that create SIP dialogs.  It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers.  The recipient can then authorize the request based on this awareness. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-target-dialog-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4538</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4539</doc-id>
        <title>Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)</title>
        <author>
            <name>T. Edwards</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF).  MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-edwards-mime-mxf-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4539</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4540</doc-id>
        <title>NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0</title>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>C. Cadar</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>midcom</kw>
        </keywords>
        <abstract><p>This document describes a protocol for controlling middleboxes such as firewalls and network address translators.  It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989.  Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-stiemerling-midcom-simco-08</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4540</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4541</doc-id>
        <title>Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches</title>
        <author>
            <name>M. Christensen</name>
        </author>
        <author>
            <name>K. Kimball</name>
        </author>
        <author>
            <name>F. Solensky</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>igmpv3</kw>
            <kw>mldv2</kw>
        </keywords>
        <abstract><p>This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches.  These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping.  Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-magma-snoop-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4541</errata-url>
        <doi>10.17487/RFC4541</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4542</doc-id>
        <title>Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>ieps</kw>
            <kw>internet emergency preparedness service</kw>
            <kw>call admission control</kw>
            <kw>cac</kw>
            <kw>phb</kw>
            <kw>per hop behavior</kw>
            <kw>multi-level precedence and preemption</kw>
            <kw>mlpp</kw>
            <kw>government emergency telecommunication service</kw>
            <kw>gets</kw>
        </keywords>
        <abstract><p>RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.</p><p> This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-mlpp-that-works-04</draft>
        <updated-by>
            <doc-id>RFC5865</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4542</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4543</doc-id>
        <title>The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>J. Viega</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>encapsulating security payload</kw>
            <kw>gcm</kw>
            <kw>galois/counter mode</kw>
            <kw>authentication header</kw>
        </keywords>
        <abstract><p>This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH).  GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mcgrew-aes-gmac-esp-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4543</errata-url>
        <doi>10.17487/RFC4543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4544</doc-id>
        <title>Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)</title>
        <author>
            <name>M. Bakke</name>
        </author>
        <author>
            <name>M. Krueger</name>
        </author>
        <author>
            <name>T. McSweeney</name>
        </author>
        <author>
            <name>J. Muchow</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>tcp/ip</kw>
            <kw>scsi</kw>
        </keywords>
        <abstract><p>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 using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-iscsi-mib-11</draft>
        <obsoleted-by>
            <doc-id>RFC7147</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4544</errata-url>
        <doi>10.17487/RFC4544</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4545</doc-id>
        <title>Definitions of Managed Objects for IP Storage User Identity Authorization</title>
        <author>
            <name>M. Bakke</name>
        </author>
        <author>
            <name>J. Muchow</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>snmp</kw>
            <kw>tcp/ip</kw>
            <kw>ips-auth-mib</kw>
        </keywords>
        <abstract><p>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 user identities and the names, addresses, and credentials required manage access control, for use with various protocols.  This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements.  It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-auth-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4545</errata-url>
        <doi>10.17487/RFC4545</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4546</doc-id>
        <title>Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces</title>
        <author>
            <name>D. Raftus</name>
        </author>
        <author>
            <name>E. Cardona</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>139</page-count>
        <keywords>
            <kw>cmts</kw>
            <kw>cm</kw>
            <kw>upstream</kw>
            <kw>downstream</kw>
            <kw>tdma</kw>
            <kw>atdma</kw>
            <kw>scdma</kw>
            <kw>quality of service</kw>
            <kw>channel utilizazation</kw>
        </keywords>
        <abstract><p>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 the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-docs-rfmibv2-14</draft>
        <obsoletes>
            <doc-id>RFC2670</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4546</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4547</doc-id>
        <title>Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems</title>
        <author>
            <name>A. Ahmad</name>
        </author>
        <author>
            <name>G. Nakanishi</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>mib</kw>
            <kw>smiv2</kw>
            <kw>DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB</kw>
        </keywords>
        <abstract><p>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 Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB.</p><p> This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-docsisevent-mib-06</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4547</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4548</doc-id>
        <title>Internet Code Point (ICP) Assignments for NSAP Addresses</title>
        <author>
            <name>E. Gray</name>
        </author>
        <author>
            <name>J. Rutemiller</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>May</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>network service access point</kw>
        </keywords>
        <abstract><p>This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values.  In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888.  In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gray-rfc1888bis-03</draft>
        <updates>
            <doc-id>RFC1888</doc-id>
            <doc-id>RFC4048</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4548</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4549</doc-id>
        <title>Synchronization Operations for Disconnected IMAP4 Clients</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>internet message access protocol</kw>
        </keywords>
        <abstract><p>This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.</p><p> This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.</p><p> This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-melnikov-imap-disc-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4549</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4550</doc-id>
        <title>Internet Email to Support Diverse Service Environments (Lemonade) Profile</title>
        <author>
            <name>S. Maes</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>internet message access protocol,</kw>
        </keywords>
        <abstract><p>This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.</p><p> The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-profile-07</draft>
        <obsoleted-by>
            <doc-id>RFC5550</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4550</errata-url>
        <doi>10.17487/RFC4550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4551</doc-id>
        <title>IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>S. Hole</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>internet mail access protocol</kw>
        </keywords>
        <abstract><p>Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.</p><p> The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.</p><p> The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.</p><p> This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imapext-condstore-09</draft>
        <obsoleted-by>
            <doc-id>RFC7162</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4551</errata-url>
        <doi>10.17487/RFC4551</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4552</doc-id>
        <title>Authentication/Confidentiality for OSPFv3</title>
        <author>
            <name>M. Gupta</name>
        </author>
        <author>
            <name>N. Melam</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>authentication header</kw>
            <kw>encapsulating security payload</kw>
            <kw>ah/esp</kw>
        </keywords>
        <abstract><p>This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-auth-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4552</errata-url>
        <doi>10.17487/RFC4552</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4553</doc-id>
        <title>Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)</title>
        <author>
            <name>A. Vainshtein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>YJ. Stein</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>SAToP</kw>
            <kw>pseudowires</kw>
            <kw>circuit emulation</kw>
            <kw>structure-agnostic emulation</kw>
        </keywords>
        <abstract><p>This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-satop-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4553</errata-url>
        <doi>10.17487/RFC4553</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4554</doc-id>
        <title>Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks</title>
        <author>
            <name>T. Chown</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Virtual Local Area Network</kw>
        </keywords>
        <abstract><p>Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation.  This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment.  In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology.  The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-vlan-usage-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4555</doc-id>
        <title>IKEv2 Mobility and Multihoming Protocol (MOBIKE)</title>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>internet key exchange</kw>
            <kw>ipsec</kw>
            <kw>internet protocol security</kw>
            <kw>vpn</kw>
            <kw>virtual private networks</kw>
        </keywords>
        <abstract><p>This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2).  MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change.  A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another.  Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mobike-protocol-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mobike</wg_acronym>
        <doi>10.17487/RFC4555</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4556</doc-id>
        <title>Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>B. Tung</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification.  These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-cat-kerberos-pk-init-34</draft>
        <updated-by>
            <doc-id>RFC6112</doc-id>
            <doc-id>RFC8062</doc-id>
            <doc-id>RFC8636</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4556</errata-url>
        <doi>10.17487/RFC4556</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4557</doc-id>
        <title>Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol.  These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-ocsp-for-pkinit-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4557</errata-url>
        <doi>10.17487/RFC4557</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4558</doc-id>
        <title>Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement</title>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>D. Prairie</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Multi-Protocol Label Switching</kw>
            <kw>mpls</kw>
            <kw>Generalized  Multi-Protocol Label Switching</kw>
            <kw>gmpls</kw>
            <kw>Traffic Engineering</kw>
            <kw>te</kw>
            <kw>rsvp-te</kw>
            <kw>gr</kw>
            <kw>graceful restart</kw>
        </keywords>
        <abstract><p>Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered.  Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE).  Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios.  The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rsvp-node-id-based-hello-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4558</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4559</doc-id>
        <title>SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</title>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>J. Brezak</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>msie</kw>
            <kw>microsoft internet explorer</kw>
            <kw>iis</kw>
            <kw>internet information services</kw>
            <kw>simple and protected negotiate</kw>
            <kw>nt lan manager</kw>
        </keywords>
        <abstract><p>This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions.  The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.  This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism.  Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-jaganathan-kerberos-http-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4559</errata-url>
        <doi>10.17487/RFC4559</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4560</doc-id>
        <title>Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations</title>
        <author>
            <name>J. Quittek</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. White</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>DISMAN-PING-MIB DEFINITIONS</kw>
            <kw>DISMAN-TRACEROUTE-MIB DEFINITIONS</kw>
            <kw>DISMAN-NSLOOKUP-MIB DEFINITIONS</kw>
        </keywords>
        <abstract><p>This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.</p><p> Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-disman-remops-mib-v2-09</draft>
        <obsoletes>
            <doc-id>RFC2925</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>disman</wg_acronym>
        <doi>10.17487/RFC4560</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4561</doc-id>
        <title>Definition of a Record Route Object (RRO) Node-Id Sub-Object</title>
        <author>
            <name>J.-P. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>multiprotocol label switching traffic engineering</kw>
            <kw>plr</kw>
            <kw>point of local repair</kw>
            <kw>igp</kw>
            <kw>interior gateway protocol</kw>
            <kw>as</kw>
            <kw>autonomous system</kw>
            <kw>abr</kw>
            <kw>area border router</kw>
            <kw>asbr</kw>
            <kw>autonomous system border router</kw>
        </keywords>
        <abstract><p>In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR).  However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS).  Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR).  This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue.  The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-nodeid-subobject-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4561</errata-url>
        <doi>10.17487/RFC4561</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4562</doc-id>
        <title>MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network</title>
        <author>
            <name>T. Melsen</name>
        </author>
        <author>
            <name>S. Blake</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Ethernet</kw>
            <kw>Access Network</kw>
            <kw>ARP</kw>
            <kw>DHCP</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.</p><p> The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-melsen-mac-forced-fwd-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4562</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4563</doc-id>
        <title>The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>E. Carrara</name>
        </author>
        <author>
            <name>V. Lehtovirta</name>
        </author>
        <author>
            <name>K. Norrman</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>security</kw>
            <kw>key management</kw>
            <kw>multicast</kw>
            <kw>broadcast</kw>
            <kw>MBMS</kw>
        </keywords>
        <abstract><p>This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol.  This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-newtype-keyid-05</draft>
        <updated-by>
            <doc-id>RFC6309</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4563</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4564</doc-id>
        <title>Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)</title>
        <author>
            <name>S. Govindan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Cheng</name>
        </author>
        <author>
            <name>ZH. Yao</name>
        </author>
        <author>
            <name>WH. Zhou</name>
        </author>
        <author>
            <name>L. Yang</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>wlan</kw>
            <kw>wireless local area network</kw>
        </keywords>
        <abstract><p>This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP).  The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol.  The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-capwap-objectives-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC4564</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4565</doc-id>
        <title>Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols</title>
        <author>
            <name>D. Loher</name>
        </author>
        <author>
            <name>D. Nelson</name>
        </author>
        <author>
            <name>O. Volinsky</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team.  The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.  his memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-capwap-eval-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC4565</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4566</doc-id>
        <title>SDP: Session Description Protocol</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>mbone</kw>
            <kw>internet</kw>
            <kw>multicast</kw>
            <kw>backbone</kw>
            <kw>multimedia</kw>
            <kw>internet addresses syntax</kw>
        </keywords>
        <abstract><p>This memo 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]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-new-26</draft>
        <obsoletes>
            <doc-id>RFC2327</doc-id>
            <doc-id>RFC3266</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8866</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4566</errata-url>
        <doi>10.17487/RFC4566</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4567</doc-id>
        <title>Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>F. Lindholm</name>
        </author>
        <author>
            <name>M. Naslund</name>
        </author>
        <author>
            <name>K. Norrman</name>
        </author>
        <author>
            <name>E. Carrara</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>key management protocol</kw>
            <kw>multimedia internet keying</kw>
            <kw>mikey</kw>
        </keywords>
        <abstract><p>This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.</p><p> General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-kmgmt-ext-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4567</errata-url>
        <doi>10.17487/RFC4567</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4568</doc-id>
        <title>Session Description Protocol (SDP) Security Descriptions for Media Streams</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>M. Baugher</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>srtp</kw>
            <kw>secure real-time transport protocol</kw>
        </keywords>
        <abstract><p>This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams.  The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange.  The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams.  The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdescriptions-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4568</errata-url>
        <doi>10.17487/RFC4568</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4569</doc-id>
        <title>Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document registers with the IANA a new media feature tag associated with the 'message' media type.  This media feature tag indicates that a particular device supports 'message' as a streaming media type.  Media feature tags can be used to route calls to devices that support certain features.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-message-tag-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4569</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4570</doc-id>
        <title>Session Description Protocol (SDP) Source Filters</title>
        <author>
            <name>B. Quinn</name>
        </author>
        <author>
            <name>R. Finlayson</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>ip</kw>
            <kw>source-filter</kw>
            <kw>ssm</kw>
            <kw>source-specific multicast</kw>
        </keywords>
        <abstract><p>This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses.  It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations.  In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-srcfilter-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4570</errata-url>
        <doi>10.17487/RFC4570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4571</doc-id>
        <title>Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport</title>
        <author>
            <name>J. Lazzaro</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>TCP-based media transport</kw>
            <kw>TCP tunnel</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP).  The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-framing-contrans-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4571</errata-url>
        <doi>10.17487/RFC4571</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4572</doc-id>
        <title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>setup</kw>
            <kw>connection</kw>
            <kw>reestablishment</kw>
        </keywords>
        <abstract><p>This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</p><p> This document extends and updates RFC 4145. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-comedia-tls-06</draft>
        <obsoleted-by>
            <doc-id>RFC8122</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4145</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4572</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4573</doc-id>
        <title>MIME Type Registration for RTP Payload Format for H.224</title>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>A. Lochbaum</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>itu h.281</kw>
            <kw>h.224</kw>
            <kw>far-end camera control</kw>
        </keywords>
        <abstract><p>In conversational video applications, far-end camera control protocol is used by participants to control the remote camera.  The protocol that is commonly used is ITU H.281 over H.224.  The document registers the H224 media type.  It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-mime-h224-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4573</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4574</doc-id>
        <title>The Session Description Protocol (SDP) Label Attribute</title>
        <author>
            <name>O. Levin</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>media level attribute</kw>
            <kw>media stream</kw>
        </keywords>
        <abstract><p>This document defines a new Session Description Protocol (SDP) media-level attribute: "label".  The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP.  The sender of the SDP document can attach the "label" attribute to a particular media stream or streams.  The application can then use the provided pointer to refer to each particular media stream in its context. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-media-label-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4574</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4575</doc-id>
        <title>A Session Initiation Protocol (SIP) Event Package for Conference State</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>O. Levin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>conference event package</kw>
            <kw>uri</kw>
            <kw>uniform resource identifier</kw>
        </keywords>
        <abstract><p>This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package.  The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI).  Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-conference-package-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4575</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4576</doc-id>
        <title>Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>service provider</kw>
            <kw>sp</kw>
            <kw>provider edge</kw>
            <kw>pe</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP.  In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE.  The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers.  The routes are then converted back to OSPF routes sent via OSPF to other CE routers.  As a result of this conversion, some of the information needed to prevent loops may be lost.  A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE.  This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-2547-dnbit-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4576</errata-url>
        <doi>10.17487/RFC4576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4577</doc-id>
        <title>OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ce</kw>
            <kw>open shortest path first</kw>
            <kw>mpls</kw>
            <kw>Multiprotocol Label Switching</kw>
        </keywords>
        <abstract><p>Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.</p><p> This document updates RFC 4364. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-ospf-2547-06</draft>
        <updates>
            <doc-id>RFC4364</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4577</errata-url>
        <doi>10.17487/RFC4577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4578</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)</title>
        <author>
            <name>M. Johnston</name>
        </author>
        <author>
            <name>S. Venaas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>efi</kw>
            <kw>extensible firmware interface</kw>
        </keywords>
        <abstract><p>We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dhc-pxe-options-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4578</errata-url>
        <doi>10.17487/RFC4578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4579</doc-id>
        <title>Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>O. Levin</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>ua</kw>
            <kw>conference-unaware</kw>
            <kw>conference-aware</kw>
            <kw>focus</kw>
        </keywords>
        <abstract><p>This specification defines conferencing call control features for the Session Initiation Protocol (SIP).  This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works.  The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs.  The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams.  The usage of the isfocus feature tag is defined.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-sipping-cc-conferencing-07</draft>
        <is-also>
            <doc-id>BCP0119</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC4579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4580</doc-id>
        <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option</title>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>June</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-subid-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4580</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4581</doc-id>
        <title>Cryptographically Generated Addresses (CGA) Extension Field Format</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>tlv</kw>
        </keywords>
        <abstract><p>This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions.  This document updates RFC 3972. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-bagnulo-cga-ext-02</draft>
        <updates>
            <doc-id>RFC3972</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4581</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4582</doc-id>
        <title>The Binary Floor Control Protocol (BFCP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>K. Drage</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>conference</kw>
        </keywords>
        <abstract><p>Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.</p><p> This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xcon-bfcp-06</draft>
        <obsoleted-by>
            <doc-id>RFC8855</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC4582</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4583</doc-id>
        <title>Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>bfcp stream</kw>
        </keywords>
        <abstract><p>This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions.  User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-bfcp-03</draft>
        <obsoleted-by>
            <doc-id>RFC8856</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4583</errata-url>
        <doi>10.17487/RFC4583</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4584</doc-id>
        <title>Extension to Sockets API for Mobile IPv6</title>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>advanced socket api</kw>
            <kw>mobility header messages</kw>
            <kw>hom address destination</kw>
            <kw>routing header type 2</kw>
            <kw>socket applications</kw>
        </keywords>
        <abstract><p>This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6.</p><p> Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-mipext-advapi-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4584</errata-url>
        <doi>10.17487/RFC4584</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4585</doc-id>
        <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>N. Sato</name>
        </author>
        <author>
            <name>C. Burmeister</name>
        </author>
        <author>
            <name>J. Rey</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>media stream</kw>
            <kw>feedback based error</kw>
            <kw>audio visual profile</kw>
        </keywords>
        <abstract><p>Real-time media streams that use RTP are, to some degree, resilient against packet losses.  Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term.  This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms).  This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented.  This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtcp-feedback-11</draft>
        <updated-by>
            <doc-id>RFC5506</doc-id>
            <doc-id>RFC8108</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4585</errata-url>
        <doi>10.17487/RFC4585</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4586</doc-id>
        <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations</title>
        <author>
            <name>C. Burmeister</name>
        </author>
        <author>
            <name>R. Hakenberg</name>
        </author>
        <author>
            <name>A. Miyazaki</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>N. Sato</name>
        </author>
        <author>
            <name>S. Fukunaga</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Real-time Transport Protocol</kw>
        </keywords>
        <abstract><p>This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF.  Unicast and multicast topologies are considered as well as several protocol and environment configurations.  The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-burmeister-avt-rtcp-feedback-sim-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4586</errata-url>
        <doi>10.17487/RFC4586</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4587</doc-id>
        <title>RTP Payload Format for H.261 Video Streams</title>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RTP-H.261</kw>
            <kw>real-time transport protocol</kw>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
        </keywords>
        <abstract><p>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.</p><p> The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.</p><p> This specification obsoletes RFC 2032. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc2032-bis-13</draft>
        <obsoletes>
            <doc-id>RFC2032</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4587</errata-url>
        <doi>10.17487/RFC4587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4588</doc-id>
        <title>RTP Retransmission Payload Format</title>
        <author>
            <name>J. Rey</name>
        </author>
        <author>
            <name>D. Leon</name>
        </author>
        <author>
            <name>A. Miyazaki</name>
        </author>
        <author>
            <name>V. Varsa</name>
        </author>
        <author>
            <name>R. Hakenberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>rtcp</kw>
            <kw>real-time transport control protocol</kw>
            <kw>RTP/AVPF</kw>
        </keywords>
        <abstract><p>RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds.  This document describes an RTP payload format for performing retransmissions.  Retransmitted RTP packets are sent in a separate stream from the original RTP stream.  It is assumed that feedback from receivers to senders is available.  In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-retransmission-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4588</errata-url>
        <doi>10.17487/RFC4588</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4589</doc-id>
        <title>Location Types Registry</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document creates a registry for describing the types of places a human or end system might be found.  The registry is then referenced by other protocols that need a common set of location terms as protocol constants.  Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-location-types-registry-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC4589</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4590</doc-id>
        <title>RADIUS Extension for Digest Authentication</title>
        <author>
            <name>B. Sterman</name>
        </author>
        <author>
            <name>D. Sadolevsky</name>
        </author>
        <author>
            <name>D. Schwartz</name>
        </author>
        <author>
            <name>D. Williams</name>
        </author>
        <author>
            <name>W. Beck</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>sip</kw>
            <kw>http</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-digest-auth-09</draft>
        <obsoleted-by>
            <doc-id>RFC5090</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4590</errata-url>
        <doi>10.17487/RFC4590</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4591</doc-id>
        <title>Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)</title>
        <author>
            <name>M. Townsley</name>
        </author>
        <author>
            <name>G. Wilkie</name>
        </author>
        <author>
            <name>S. Booth</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>J. Lau</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>data link protocols</kw>
            <kw>frame encapsulation</kw>
            <kw>virtual-circuit creation and deletion</kw>
            <kw>status change notification</kw>
        </keywords>
        <abstract><p>The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks.  This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-pwe3-fr-07</draft>
        <updated-by>
            <doc-id>RFC5641</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4591</errata-url>
        <doi>10.17487/RFC4591</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4592</doc-id>
        <title>The Role of Wildcards in the Domain Name System</title>
        <author>
            <name>E. Lewis</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>cname</kw>
        </keywords>
        <abstract><p>This is an update to the wildcard definition of RFC 1034.  The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed.  The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-wcard-clarify-11</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC2672</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4592</errata-url>
        <doi>10.17487/RFC4592</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4593</doc-id>
        <title>Generic Threats to Routing Protocols</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>S. Murphy</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>threat sources</kw>
            <kw>threat capability</kw>
            <kw>threat action</kw>
            <kw>threat consequences</kw>
        </keywords>
        <abstract><p>Routing protocols are subject to attacks that can harm individual users or network operations as a whole.  This document provides a description and a summary of generic threats that affect routing protocols in general.  This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rpsec-routing-threats-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rpsec</wg_acronym>
        <doi>10.17487/RFC4593</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4594</doc-id>
        <title>Configuration Guidelines for DiffServ Service Classes</title>
        <author>
            <name>J. Babiarz</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>differentiated services code points</kw>
            <kw>traffic conditioners</kw>
            <kw>per-hop behaviors</kw>
            <kw>phb</kw>
            <kw>dscp</kw>
            <kw>active queue management</kw>
            <kw>aqm</kw>
        </keywords>
        <abstract><p>This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms.  There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-diffserv-service-classes-02</draft>
        <updated-by>
            <doc-id>RFC5865</doc-id>
            <doc-id>RFC8622</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4594</errata-url>
        <doi>10.17487/RFC4594</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4595</doc-id>
        <title>Use of IKEv2 in the Fibre Channel Security Association Management Protocol</title>
        <author>
            <name>F. Maino</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet key exchange</kw>
        </keywords>
        <abstract><p>This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol.  This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types.  This document specifies these IKEv2 extensions and allocates identifiers for them.  Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-maino-fcsp-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4595</errata-url>
        <doi>10.17487/RFC4595</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4596</doc-id>
        <title>Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP).  It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-callerprefs-usecases-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4596</errata-url>
        <doi>10.17487/RFC4596</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4597</doc-id>
        <title>Conferencing Scenarios</title>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>N. Ismail</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>multimedia</kw>
            <kw>voice</kw>
            <kw>video</kw>
            <kw>text</kw>
            <kw>interactive text</kw>
            <kw>xcon</kw>
        </keywords>
        <abstract><p>This document describes multimedia conferencing scenarios.  It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions.  These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-xcon-conference-scenarios-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC4597</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4598</doc-id>
        <title>Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio</title>
        <author>
            <name>B. Link</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>encoded audio data</kw>
            <kw>multichannel audio coding format</kw>
        </keywords>
        <abstract><p>This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data.  E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media.  E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats.  The RTP payload format as presented in this document includes support for data fragmentation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-eac3-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4598</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4599</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4600</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4601</doc-id>
        <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>H. Holbrook</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>150</page-count>
        <keywords>
            <kw>PIM-SM</kw>
            <kw>routing</kw>
            <kw>message</kw>
            <kw>type</kw>
            <kw>timers</kw>
            <kw>flags</kw>
        </keywords>
        <abstract><p>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.</p><p> This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-sm-v2-new-12</draft>
        <obsoletes>
            <doc-id>RFC2362</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7761</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5059</doc-id>
            <doc-id>RFC5796</doc-id>
            <doc-id>RFC6226</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4601</errata-url>
        <doi>10.17487/RFC4601</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4602</doc-id>
        <title>Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis</title>
        <author>
            <name>T. Pusateri</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pim-proposed-req-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC4602</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4603</doc-id>
        <title>Additional Values for the NAS-Port-Type Attribute</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>G. Weber</name>
        </author>
        <author>
            <name>R. Foltak</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>radius</kw>
            <kw>Remote Authentication Dial-In User Service</kw>
        </keywords>
        <abstract><p>This document defines a set of values for the NAS-Port-Type RADIUS Attribute.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-zorn-radius-port-type-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4604</doc-id>
        <title>Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast</title>
        <author>
            <name>H. Holbrook</name>
        </author>
        <author>
            <name>B. Cain</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ssm</kw>
        </keywords>
        <abstract><p>The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively.  Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission.  This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast.  This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-holbrook-idmr-igmpv3-ssm-08</draft>
        <updates>
            <doc-id>RFC3376</doc-id>
            <doc-id>RFC3810</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <doi>10.17487/RFC4604</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4605</doc-id>
        <title>Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>H. He</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>H. Sandick</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>In certain topologies, it is not necessary to run a multicast routing protocol.  It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information.  This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-magma-igmp-proxy-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4605</errata-url>
        <doi>10.17487/RFC4605</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4606</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>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document provides minor clarification to RFC 3946.</p><p> 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 GMPLS signaling is used. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rfc3946bis-01</draft>
        <obsoletes>
            <doc-id>RFC3946</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6344</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4606</errata-url>
        <doi>10.17487/RFC4606</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4607</doc-id>
        <title>Source-Specific Multicast for IP</title>
        <author>
            <name>H. Holbrook</name>
        </author>
        <author>
            <name>B. Cain</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ipv4</kw>
            <kw>ssm</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols.  For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use.  This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ssm-arch-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ssm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4607</errata-url>
        <doi>10.17487/RFC4607</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4608</doc-id>
        <title>Source-Specific Protocol Independent Multicast in 232/8</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>R. Rockell</name>
        </author>
        <author>
            <name>G. Shepherd</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ip</kw>
            <kw>ssm</kw>
        </keywords>
        <abstract><p>IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols.  This document defines operational recommendations to ensure source-specific behavior within the 232/8 range.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-mboned-ssm232-08</draft>
        <is-also>
            <doc-id>BCP0120</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC4608</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4609</doc-id>
        <title>Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements</title>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>R. Lehtonen</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>security threats</kw>
            <kw>intra-domain</kw>
            <kw>inter-domain</kw>
            <kw>any-source multicast</kw>
            <kw>asm</kw>
            <kw>source-specific multicast</kw>
            <kw>ssm</kw>
            <kw>embedded rendezvous point</kw>
            <kw>embedded-rp</kw>
        </keywords>
        <abstract><p>This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures.  Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism.  This memo also describes enhancements to the protocol operations that mitigate the identified threats.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mboned-mroutesec-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC4609</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4610</doc-id>
        <title>Anycast-RP Using Protocol Independent Multicast (PIM)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>Y. Cai</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>rendezvous point</kw>
            <kw>rp</kw>
            <kw>msdp register</kw>
            <kw>multicast source discovery</kw>
            <kw>register-stop</kw>
        </keywords>
        <abstract><p>This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only.  Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-anycast-rp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC4610</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4611</doc-id>
        <title>Multicast Source Discovery Protocol (MSDP) Deployment Scenarios</title>
        <author>
            <name>M. McBride</name>
        </author>
        <author>
            <name>J. Meylor</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>pim-sm</kw>
            <kw>protocol independent multicast sparse mode</kw>
        </keywords>
        <abstract><p>This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-mboned-msdp-deploy-06</draft>
        <is-also>
            <doc-id>BCP0121</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC4611</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4612</doc-id>
        <title>Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>H. Tamura</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>itu-t recommendation t.38</kw>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
        </keywords>
        <abstract><p>This document defines the MIME sub-type audio/t38.  The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38.  This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-jones-avt-audio-t38-05</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4612</errata-url>
        <doi>10.17487/RFC4612</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4613</doc-id>
        <title>Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI)</title>
        <author>
            <name>P. Frojdh</name>
        </author>
        <author>
            <name>U. Lindgren</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>dls</kw>
        </keywords>
        <abstract><p>This document serves to register a media type for Downloadable Sounds.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-westerlund-mime-dls-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4613</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4614</doc-id>
        <title>A Roadmap for Transmission Control Protocol (TCP) Specification Documents</title>
        <author>
            <name>M. Duke</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>W. Eddy</name>
        </author>
        <author>
            <name>E. Blanton</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP).  This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series.  This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-roadmap-06</draft>
        <obsoleted-by>
            <doc-id>RFC7414</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6247</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC4614</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4615</doc-id>
        <title>The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)</title>
        <author>
            <name>J. Song</name>
        </author>
        <author>
            <name>R. Poovendran</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>T. Iwata</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>ip security</kw>
            <kw>pseudo-random function</kw>
        </keywords>
        <abstract><p>Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES).  This memo describes such an algorithm, called AES-CMAC-PRF-128.  It supports fixed and variable key sizes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-songlee-aes-cmac-prf-128-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4616</doc-id>
        <title>The PLAIN Simple Authentication and Security Layer (SASL) Mechanism</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>data confidentiality</kw>
        </keywords>
        <abstract><p>This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism.  The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sasl-plain-09</draft>
        <updates>
            <doc-id>RFC2595</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4616</errata-url>
        <doi>10.17487/RFC4616</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4617</doc-id>
        <title>A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project</title>
        <author>
            <name>J. Kornijenko</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>general contractor</kw>
            <kw>Olimps LTD</kw>
            <kw>subcontractors</kw>
            <kw>ABC software LTD</kw>
            <kw>Microsoft Latvia LTD</kw>
            <kw>Riga Internet eXchange Technologies LTD</kw>
            <kw>RIX</kw>
            <kw>Microlink LTD</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (Latvian abbreviation IVIS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kornijenko-ivis-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4617</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4618</doc-id>
        <title>Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>G. Heron</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>pw</kw>
            <kw>pseudowire</kw>
            <kw>point to point protocol</kw>
            <kw>pdu</kw>
            <kw>packet data unit</kw>
        </keywords>
        <abstract><p>A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol.  This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks.  This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-hdlc-ppp-encap-mpls-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC4618</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4619</doc-id>
        <title>Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Kawa</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>pseudowire</kw>
            <kw>psn</kw>
            <kw>packet switched network</kw>
            <kw>pw</kw>
        </keywords>
        <abstract><p>A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN).  This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-frame-relay-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4619</errata-url>
        <doi>10.17487/RFC4619</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4620</doc-id>
        <title>IPv6 Node Information Queries</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name.  IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ipngwg-icmp-name-lookups-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC4620</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4621</doc-id>
        <title>Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>internet key exchange</kw>
        </keywords>
        <abstract><p>The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).</p><p> This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mobike-design-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mobike</wg_acronym>
        <doi>10.17487/RFC4621</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4622</doc-id>
        <title>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>Internationalized Resource Identifier</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>Jabber</kw>
            <kw>xmpp</kw>
            <kw>iri</kw>
            <kw>uri</kw>
        </keywords>
        <abstract><p>This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-saintandre-xmpp-iri-04</draft>
        <obsoleted-by>
            <doc-id>RFC5122</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4622</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4623</doc-id>
        <title>Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-fragmentation-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4623</errata-url>
        <doi>10.17487/RFC4623</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4624</doc-id>
        <title>Multicast Source Discovery Protocol (MSDP) MIB</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>MSDP-MIB</kw>
        </keywords>
        <abstract><p>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 managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mboned-msdp-mib-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC4624</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4625</doc-id>
        <title>Fibre Channel Routing Information MIB</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Kode</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-ROUTE-MIB</kw>
        </keywords>
        <abstract><p>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 routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-rtm-mib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC4625</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4626</doc-id>
        <title>MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>V. Gaonkar</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-FSPF-MIB</kw>
        </keywords>
        <abstract><p>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 network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-fspf-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC4626</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4627</doc-id>
        <title>The application/json Media Type for JavaScript Object Notation (JSON)</title>
        <author>
            <name>D. Crockford</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>data interchange format</kw>
            <kw>ECMAScript Programming Language Standard</kw>
        </keywords>
        <abstract><p>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-crockford-jsonorg-json-04</draft>
        <obsoleted-by>
            <doc-id>RFC7159</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4627</errata-url>
        <doi>10.17487/RFC4627</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4628</doc-id>
        <title>RTP Payload Format for H.263 Moving RFC 2190 to Historic Status</title>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>itu-t</kw>
            <kw>itu telecommunication standardization sector</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract><p>The first RFC that describes RTP payload format for ITU Telecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190.  This specification discusses why to move RFC 2190 to historic status.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-avt-rfc2190-to-historic-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4628</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4629</doc-id>
        <title>RTP Payload Format for ITU-T Rec. H.263 Video</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>G. Sullivan</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>R. Even</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
        </keywords>
        <abstract><p>This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.</p><p> The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.</p><p> The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc2429-bis-09</draft>
        <obsoletes>
            <doc-id>RFC2429</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3555</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4629</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4630</doc-id>
        <title>Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Santesson</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>utf8string</kw>
            <kw>printablestring</kw>
        </keywords>
        <abstract><p>This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280.  The use of UTF8String and PrintableString are the preferred encoding.  The requirement for exclusive use of UTF8String after December 31, 2003 is removed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-cert-utf8-03</draft>
        <obsoleted-by>
            <doc-id>RFC5280</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC4630</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4631</doc-id>
        <title>Link Management Protocol (LMP) Management Information Base (MIB)</title>
        <author>
            <name>M. Dubuc</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>J. Lang</name>
        </author>
        <author>
            <name>E. McGinnis</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>lmp-mib</kw>
        </keywords>
        <abstract><p>This document provides minor corrections to and obsoletes RFC 4327.</p><p> 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 modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rfc4327bis-01</draft>
        <obsoletes>
            <doc-id>RFC4327</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4631</errata-url>
        <doi>10.17487/RFC4631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4632</doc-id>
        <title>Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan</title>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>CIDR-STRA</kw>
            <kw>global routing state</kw>
        </keywords>
        <abstract><p>This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state.  This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-grow-rfc1519bis-04</draft>
        <obsoletes>
            <doc-id>RFC1519</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0122</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4632</errata-url>
        <doi>10.17487/RFC4632</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4633</doc-id>
        <title>Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists.  This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-hartman-mailinglist-experiment-03</draft>
        <updated-by>
            <doc-id>RFC8717</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4633</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4634</doc-id>
        <title>US Secure Hash Algorithms (SHA and HMAC-SHA)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>July</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>108</page-count>
        <keywords>
            <kw>fips</kw>
            <kw>federal information processing standard</kw>
            <kw>sha-224</kw>
            <kw>sha-256</kw>
            <kw>sha-384</kw>
            <kw>sha-512</kw>
        </keywords>
        <abstract><p>The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.</p><p> Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-eastlake-sha2-02</draft>
        <obsoleted-by>
            <doc-id>RFC6234</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3174</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4634</errata-url>
        <doi>10.17487/RFC4634</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4635</doc-id>
        <title>HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>resource record</kw>
            <kw>rr</kw>
            <kw>cryptographic message authentication code</kw>
            <kw>cmac</kw>
        </keywords>
        <abstract><p>Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code.  Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms.  This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-tsig-sha-06</draft>
        <obsoleted-by>
            <doc-id>RFC8945</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2845</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4635</errata-url>
        <doi>10.17487/RFC4635</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4636</doc-id>
        <title>Foreign Agent Error Extension for Mobile IPv4</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4.  Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent.  The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-faerr-02</draft>
        <updates>
            <doc-id>RFC3344</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4636</errata-url>
        <doi>10.17487/RFC4636</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4637</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4638</doc-id>
        <title>Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)</title>
        <author>
            <name>P. Arberg</name>
        </author>
        <author>
            <name>D. Kourkouzelis</name>
        </author>
        <author>
            <name>M. Duckett</name>
        </author>
        <author>
            <name>T. Anschutz</name>
        </author>
        <author>
            <name>J. Moisand</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492.  This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-arberg-pppoe-mtu-gt1492-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pppext</wg_acronym>
        <doi>10.17487/RFC4638</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4639</doc-id>
        <title>Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems</title>
        <author>
            <name>R. Woundy</name>
        </author>
        <author>
            <name>K. Marez</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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 Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.</p><p> This memo obsoletes RFC 2669. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-device-mibv2-11</draft>
        <obsoletes>
            <doc-id>RFC2669</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4639</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4640</doc-id>
        <title>Problem Statement for bootstrapping Mobile IPv6 (MIPv6)</title>
        <author>
            <name>A. Patel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Giaretta</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>mobile node</kw>
        </keywords>
        <abstract><p>A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent.  The process of obtaining this information is called bootstrapping.  This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-bootstrap-ps-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4640</errata-url>
        <doi>10.17487/RFC4640</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4641</doc-id>
        <title>DNSSEC Operational Practices</title>
        <author>
            <name>O. Kolkman</name>
        </author>
        <author>
            <name>R. Gieben</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>domain name space</kw>
            <kw>security extensions</kw>
            <kw>zone administrator</kw>
            <kw>DNS-SOC</kw>
            <kw>cryptology</kw>
            <kw>resource records</kw>
            <kw>rrs</kw>
        </keywords>
        <abstract><p>This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</p><p> The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</p><p> This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-operational-practices-08</draft>
        <obsoletes>
            <doc-id>RFC2541</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6781</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4641</errata-url>
        <doi>10.17487/RFC4641</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4642</doc-id>
        <title>Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <author>
            <name>J. Vinocur</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>single link confidentiality</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS).  The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nntpext-tls-nntp-09</draft>
        <updated-by>
            <doc-id>RFC8143</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>nntpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4642</errata-url>
        <doi>10.17487/RFC4642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4643</doc-id>
        <title>Network News Transfer Protocol (NNTP) Extension for Authentication</title>
        <author>
            <name>J. Vinocur</name>
        </author>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>authinfo user/pass</kw>
            <kw>authinfo simple</kw>
            <kw>authinfo generic</kw>
            <kw>sasl</kw>
            <kw>simple authentication and security layer</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.</p><p> This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nntpext-authinfo-10</draft>
        <updates>
            <doc-id>RFC2980</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>nntpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4643</errata-url>
        <doi>10.17487/RFC4643</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4644</doc-id>
        <title>Network News Transfer Protocol (NNTP) Extension for Streaming Feeds</title>
        <author>
            <name>J. Vinocur</name>
        </author>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>check</kw>
            <kw>takethis</kw>
            <kw>mode stream</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.</p><p> This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nntpext-streaming-06</draft>
        <updates>
            <doc-id>RFC2980</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>nntpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4644</errata-url>
        <doi>10.17487/RFC4644</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4645</doc-id>
        <title>Initial Language Subtag Registry</title>
        <author>
            <name>D. Ewell</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>iana</kw>
        </keywords>
        <abstract><p>This memo defined the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages.  Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ltru-initial-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ltru</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4645</errata-url>
        <doi>10.17487/RFC4645</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4646</doc-id>
        <title>Tags for Identifying Languages</title>
        <author>
            <name>A. Phillips</name>
        </author>
        <author>
            <name>M. Davis</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>Lang-Tag</kw>
        </keywords>
        <abstract><p>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ltru-registry-14</draft>
        <obsoletes>
            <doc-id>RFC3066</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5646</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ltru</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4646</errata-url>
        <doi>10.17487/RFC4646</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4647</doc-id>
        <title>Matching of Language Tags</title>
        <author>
            <name>A. Phillips</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Davis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Lang-Tag</kw>
        </keywords>
        <abstract><p>This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences.  It also describes different mechanisms for comparing and matching these to language tags.  Two kinds of matching mechanisms, filtering and lookup, are defined.  Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag.  Possible applications include language negotiation or content selection.  This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ltru-matching-15</draft>
        <obsoletes>
            <doc-id>RFC3066</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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ltru</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4647</errata-url>
        <doi>10.17487/RFC4647</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4648</doc-id>
        <title>The Base16, Base32, and Base64 Data Encodings</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>schemes</kw>
            <kw>data</kw>
            <kw>line-feeds</kw>
            <kw>alphabets</kw>
            <kw>base encoding</kw>
            <kw>hex</kw>
        </keywords>
        <abstract><p>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, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-josefsson-rfc3548bis-04</draft>
        <obsoletes>
            <doc-id>RFC3548</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4648</errata-url>
        <doi>10.17487/RFC4648</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4649</doc-id>
        <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option</title>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-remoteid-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4649</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4650</doc-id>
        <title>HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>M. Euchner</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Multicast security</kw>
            <kw>MIKEY</kw>
            <kw>key management</kw>
            <kw>Diffie-Hellman</kw>
            <kw>key agreement</kw>
            <kw>HMAC</kw>
        </keywords>
        <abstract><p>This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830.  In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged.  This protocol addresses the security and performance constraints of multimedia key management in MIKEY. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-mikey-dhhmac-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4650</errata-url>
        <doi>10.17487/RFC4650</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4651</doc-id>
        <title>A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization</title>
        <author>
            <name>C. Vogt</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Mobile IPv6</kw>
            <kw>Route Optimization</kw>
            <kw>Enhancement</kw>
            <kw>Mobility</kw>
            <kw>Handoff</kw>
            <kw>IP Address Tests</kw>
            <kw>Protected Tunnels</kw>
            <kw>Optimistic Behavior</kw>
            <kw>Proactive IP Address Tests</kw>
            <kw>Concurrent Care-of Address Tests</kw>
            <kw>Diverted Routing</kw>
            <kw>Credit-Based Authorization</kw>
            <kw>Heuristic Monitoring</kw>
            <kw>Crypto-Based Identifiers</kw>
            <kw>Pre-Configuration</kw>
            <kw>Semi-Permanent Security Associations</kw>
            <kw>Delegation</kw>
            <kw>Mobile Networks</kw>
            <kw>Location Privacy</kw>
        </keywords>
        <abstract><p>This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-mobopts-ro-enhancements-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC4651</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4652</doc-id>
        <title>Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements</title>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <author>
            <name>J. Sadler</name>
        </author>
        <author>
            <name>S. Shew</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>gmpls</kw>
            <kw>generalized multiprotocol label switching</kw>
            <kw>otn</kw>
            <kw>optical transport networks</kw>
            <kw>sonet</kw>
            <kw>sdh</kw>
            <kw>synchronous optical network</kw>
            <kw>synchronous digital hierarchy</kw>
            <kw>itu-t</kw>
        </keywords>
        <abstract><p>The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).</p><p> This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ason-routing-eval-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4652</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4653</doc-id>
        <title>Improving the Robustness of TCP to Non-Congestion Events</title>
        <author>
            <name>S. Bhandarkar</name>
        </author>
        <author>
            <name>A. L. N. Reddy</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>E. Blanton</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ncr</kw>
            <kw>non-congestion robustness</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>This document specifies Non-Congestion Robustness (NCR) for TCP.  In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion.  One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments.  However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance.  TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering.  This document specifies the changes to TCP, as well as the costs and benefits of these modifications.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-dcr-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4653</errata-url>
        <doi>10.17487/RFC4653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4654</doc-id>
        <title>TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification</title>
        <author>
            <name>J. Widmer</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>streaming media</kw>
            <kw>multicase</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document specifies TCP-Friendly Multicast Congestion Control (TFMCC).  TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment.  It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions.  TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-rmt-bb-tfmcc-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4654</errata-url>
        <doi>10.17487/RFC4654</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4655</doc-id>
        <title>A Path Computation Element (PCE)-Based Architecture</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>J.-P. Vasseur</name>
        </author>
        <author>
            <name>J. Ash</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>traffic engineering</kw>
        </keywords>
        <abstract><p>Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</p><p> This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-architecture-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC4655</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4656</doc-id>
        <title>A One-way Active Measurement Protocol (OWAMP)</title>
        <author>
            <name>S. Shalunov</name>
        </author>
        <author>
            <name>B. Teitelbaum</name>
        </author>
        <author>
            <name>A. Karp</name>
        </author>
        <author>
            <name>J. Boote</name>
        </author>
        <author>
            <name>M. Zekauskas</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>unidirectional characteristics</kw>
            <kw>one-way</kw>
            <kw>gps</kw>
            <kw>cdma</kw>
        </keywords>
        <abstract><p>The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss.  High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA).  OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-owdp-16</draft>
        <updated-by>
            <doc-id>RFC7717</doc-id>
            <doc-id>RFC7718</doc-id>
            <doc-id>RFC8545</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC4656</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4657</doc-id>
        <title>Path Computation Element (PCE) Communication Protocol Generic Requirements</title>
        <author>
            <name>J. Ash</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J.L. Le Roux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>pce architecture</kw>
            <kw>pcc</kw>
            <kw>path computation client</kw>
        </keywords>
        <abstract><p>The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs).  This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable.  Subsequent documents will specify application-specific requirements for the PCE communication protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-comm-protocol-gen-reqs-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC4657</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4658</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4659</doc-id>
        <title>BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN</title>
        <author>
            <name>J. De Clercq</name>
        </author>
        <author>
            <name>D. Ooms</name>
        </author>
        <author>
            <name>M. Carugi</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>service provider</kw>
            <kw>border gateway protocol</kw>
            <kw>multiprotocol label switching</kw>
        </keywords>
        <abstract><p>This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".</p><p> This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-bgp-ipv6-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4659</errata-url>
        <doi>10.17487/RFC4659</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4660</doc-id>
        <title>Functional Description of Event Notification Filtering</title>
        <author>
            <name>H. Khartabil</name>
        </author>
        <author>
            <name>E. Leppanen</name>
        </author>
        <author>
            <name>M. Lonnfors</name>
        </author>
        <author>
            <name>J. Costa-Requena</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>event state subscription</kw>
            <kw>presence</kw>
            <kw>filter criteria</kw>
        </keywords>
        <abstract><p>The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.</p><p> This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-event-filter-funct-05</draft>
        <updated-by>
            <doc-id>RFC6665</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4660</errata-url>
        <doi>10.17487/RFC4660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4661</doc-id>
        <title>An Extensible Markup Language (XML)-Based Format for Event Notification Filtering</title>
        <author>
            <name>H. Khartabil</name>
        </author>
        <author>
            <name>E. Leppanen</name>
        </author>
        <author>
            <name>M. Lonnfors</name>
        </author>
        <author>
            <name>J. Costa-Requena</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>event state subscription</kw>
            <kw>presence</kw>
            <kw>filter criteria</kw>
        </keywords>
        <abstract><p>The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource.  The document does not describe a mechanism whereby filtering of event notification information can be achieved.  Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered.  In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain.  This document presents a format in the form of an XML document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-filter-format-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4661</errata-url>
        <doi>10.17487/RFC4661</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4662</doc-id>
        <title>A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists</title>
        <author>
            <name>A. B. Roach</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources.  Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-event-list-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4662</errata-url>
        <doi>10.17487/RFC4662</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4663</doc-id>
        <title>Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-harrington-8021-mib-transition-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4663</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4664</doc-id>
        <title>Framework for Layer 2 Virtual Private Networks (L2VPNs)</title>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <abstract><p>This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs).  This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l2vpn-l2-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4664</errata-url>
        <doi>10.17487/RFC4664</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4665</doc-id>
        <title>Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks</title>
        <author>
            <name>W. Augustyn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Serbest</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>l2vpn</kw>
            <kw>ppvpn</kw>
            <kw>virtual private wire service</kw>
            <kw>vpws</kw>
            <kw>virtual private lan service</kw>
            <kw>vpls</kw>
        </keywords>
        <abstract><p>This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs).  It first provides taxonomy and terminology and states generic and general service requirements.  It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS).  Detailed requirements are expressed from both a customer as well as a service provider perspectives.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l2vpn-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC4665</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4666</doc-id>
        <title>Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)</title>
        <author>
            <name>K. Morneault</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Pastor-Balbas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>mtp</kw>
            <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>
        <abstract><p>This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol.  Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains.  This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications.  It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport.  This document obsoletes RFC 3332. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sigtran-rfc3332bis-06</draft>
        <obsoletes>
            <doc-id>RFC3332</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4666</errata-url>
        <doi>10.17487/RFC4666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4667</doc-id>
        <title>Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)</title>
        <author>
            <name>W. Luo</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>L2VPN</kw>
            <kw>L2TP</kw>
            <kw>L2TPv3</kw>
            <kw>pseudowire</kw>
            <kw>forwarder</kw>
        </keywords>
        <abstract><p>The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols.  One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN).  This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-l2vpn-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC4667</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4668</doc-id>
        <title>RADIUS Authentication Client MIB for IPv6</title>
        <author>
            <name>D. Nelson</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>security</kw>
            <kw>remote access dialin user service</kw>
            <kw>RADIUS-AUTH-CLIENT-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.</p><p> This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-rfc2618bis-04</draft>
        <obsoletes>
            <doc-id>RFC2618</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4668</errata-url>
        <doi>10.17487/RFC4668</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4669</doc-id>
        <title>RADIUS Authentication Server MIB for IPv6</title>
        <author>
            <name>D. Nelson</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>security</kw>
            <kw>remote access dialin user service</kw>
            <kw>RADIUS-AUTH-SERVER-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.</p><p> This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-rfc2619bis-04</draft>
        <obsoletes>
            <doc-id>RFC2619</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4669</errata-url>
        <doi>10.17487/RFC4669</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4670</doc-id>
        <title>RADIUS Accounting Client MIB for IPv6</title>
        <author>
            <name>D. Nelson</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>security</kw>
            <kw>remote access dialin user service</kw>
            <kw>RADIUS-ACC-CLIENT-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients.</p><p> This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radext-rfc2620bis-04</draft>
        <obsoletes>
            <doc-id>RFC2620</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4670</errata-url>
        <doi>10.17487/RFC4670</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4671</doc-id>
        <title>RADIUS Accounting Server MIB for IPv6</title>
        <author>
            <name>D. Nelson</name>
        </author>
        <date>
            <month>August</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>security</kw>
            <kw>remote access dialin user service</kw>
            <kw>RADIUS-ACC-SERVER-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers.</p><p> This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radext-rfc2621bis-04</draft>
        <obsoletes>
            <doc-id>RFC2621</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4671</errata-url>
        <doi>10.17487/RFC4671</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4672</doc-id>
        <title>RADIUS Dynamic Authorization Client MIB</title>
        <author>
            <name>S. De Cnodder</name>
        </author>
        <author>
            <name>N. Jonnala</name>
        </author>
        <author>
            <name>M. Chiba</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>dac</kw>
            <kw>dynamic authorization client</kw>
            <kw>RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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 the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radext-dynauth-client-mib-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4672</errata-url>
        <doi>10.17487/RFC4672</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4673</doc-id>
        <title>RADIUS Dynamic Authorization Server MIB</title>
        <author>
            <name>S. De Cnodder</name>
        </author>
        <author>
            <name>N. Jonnala</name>
        </author>
        <author>
            <name>M. Chiba</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>remote authentication dial-in user service</kw>
            <kw>RADIUS-DYNAUTH-SERVER-MIB</kw>
        </keywords>
        <abstract><p>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 the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-radext-dynauth-server-mib-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4673</errata-url>
        <doi>10.17487/RFC4673</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4674</doc-id>
        <title>Requirements for Path Computation Element (PCE) Discovery</title>
        <author>
            <name>J.L. Le Roux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>path computation client</kw>
            <kw>pcc</kw>
        </keywords>
        <abstract><p>This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection.  It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-discovery-reqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC4674</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4675</doc-id>
        <title>RADIUS Attributes for Virtual LAN and Priority Support</title>
        <author>
            <name>P. Congdon</name>
        </author>
        <author>
            <name>M. Sanchez</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>local area network</kw>
        </keywords>
        <abstract><p>This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks.  These attributes are usable within either RADIUS or Diameter. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-vlan-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4675</errata-url>
        <doi>10.17487/RFC4675</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4676</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>lci</kw>
            <kw>local configuration information</kw>
        </keywords>
        <abstract><p>This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server.  The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information.  The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-dhcp-civil-09</draft>
        <obsoleted-by>
            <doc-id>RFC4776</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4676</errata-url>
        <doi>10.17487/RFC4676</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4677</doc-id>
        <title>The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>S. Harris</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>meeting</kw>
        </keywords>
        <abstract><p>This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process.  It is not a formal IETF process document but instead an informational overview.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hoffman-taobis-08</draft>
        <obsoletes>
            <doc-id>RFC3160</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6722</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4677</errata-url>
        <doi>10.17487/RFC4677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4678</doc-id>
        <title>Server/Application State Protocol v1</title>
        <author>
            <name>A. Bivens</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>sasp</kw>
            <kw>server/application state protocol</kw>
        </keywords>
        <abstract><p>Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion.  Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work.  The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-bivens-sasp-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4678</errata-url>
        <doi>10.17487/RFC4678</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4679</doc-id>
        <title>DSL Forum Vendor-Specific RADIUS Attributes</title>
        <author>
            <name>V. Mammoliti</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>P. Arberg</name>
        </author>
        <author>
            <name>R. Rennison</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>vsa</kw>
            <kw>dsl</kw>
            <kw>digital subscriber line</kw>
        </keywords>
        <abstract><p>This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum.</p><p> These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mammoliti-radius-dsl-vsa-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4679</errata-url>
        <doi>10.17487/RFC4679</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4680</doc-id>
        <title>TLS Handshake Message for Supplemental Data</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>This specification defines a TLS handshake message for exchange of supplemental application data.  TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server.  Then, the supplemental data handshake message is used to exchange the data.  Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-santesson-tls-supp-02</draft>
        <updates>
            <doc-id>RFC4346</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8447</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4681</doc-id>
        <title>TLS User Mapping Extension</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>A. Medvinsky</name>
        </author>
        <author>
            <name>J. Ball</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>transport layer security</kw>
            <kw>handshake message</kw>
            <kw>upndomainhint</kw>
        </keywords>
        <abstract><p>This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680.  One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database.  Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-santesson-tls-ume-07</draft>
        <updates>
            <doc-id>RFC4346</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4681</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4682</doc-id>
        <title>Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices</title>
        <author>
            <name>E. Nechamkin</name>
        </author>
        <author>
            <name>J-F. Mule</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>PKTC-IETF-MTA-MIB</kw>
        </keywords>
        <abstract><p>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 Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-pktc-mtamib-09</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC4682</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4683</doc-id>
        <title>Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)</title>
        <author>
            <name>J. Park</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>H. Lee</name>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>subjectaltname</kw>
            <kw>privacy-sensitive</kw>
            <kw>identifiers</kw>
            <kw>pepsi</kw>
        </keywords>
        <abstract><p>This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.</p><p> The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-sim-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4683</errata-url>
        <doi>10.17487/RFC4683</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4684</doc-id>
        <title>Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)</title>
        <author>
            <name>P. Marques</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>J. Guichard</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>mp-bgp</kw>
            <kw>bgp speakers</kw>
            <kw>route target</kw>
        </keywords>
        <abstract><p>This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information.  This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system.  This document updates RFC 4364. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-rt-constrain-02</draft>
        <updates>
            <doc-id>RFC4364</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4684</errata-url>
        <doi>10.17487/RFC4684</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4685</doc-id>
        <title>Atom Threading Extensions</title>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>atom syndication format</kw>
            <kw>extension</kw>
            <kw>threading</kw>
            <kw>syndication</kw>
        </keywords>
        <abstract><p>This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-snell-atompub-feed-thread-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4685</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4686</doc-id>
        <title>Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)</title>
        <author>
            <name>J. Fenton</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>email</kw>
            <kw>attack</kw>
            <kw>authentication</kw>
            <kw>signature</kw>
            <kw>ssp</kw>
        </keywords>
        <abstract><p>This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail.  It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dkim-threats-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <doi>10.17487/RFC4686</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4687</doc-id>
        <title>Operations and Management (OAM) Requirements  for Point-to-Multipoint MPLS Networks</title>
        <author>
            <name>S. Yasukawa</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>pwmp</kw>
            <kw>lsp</kw>
            <kw>p2mp mpls lsp</kw>
        </keywords>
        <abstract><p>Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.</p><p> For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.</p><p> This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-p2mp-oam-reqs-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4687</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4688</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D</title>
        <author>
            <name>S. Rushing</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-rushing-s1000d-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4688</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4689</doc-id>
        <title>Terminology for Benchmarking Network-layer Traffic Control Mechanisms</title>
        <author>
            <name>S. Poretsky</name>
        </author>
        <author>
            <name>J. Perser</name>
        </author>
        <author>
            <name>S. Erramilli</name>
        </author>
        <author>
            <name>S. Khurana</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>packet classification</kw>
        </keywords>
        <abstract><p>This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria.  The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms.  Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-dsmterm-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4689</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4690</doc-id>
        <title>Review and Recommendations for Internationalized Domain Names (IDNs)</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>C. Karp</name>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>September</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>domain namespace</kw>
            <kw>idna</kw>
            <kw>internationalizing domain names in applications</kw>
        </keywords>
        <abstract><p>This note describes issues raised by the deployment and use of Internationalized Domain Names.  It describes problems both at the time of registration and for use of those names in the DNS.  It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF.  In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-idn-nextsteps-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4690</errata-url>
        <doi>10.17487/RFC4690</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4691</doc-id>
        <title>Guidelines for Acting as an IETF Liaison to Another Organization</title>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internet engineering task force</kw>
            <kw>sdo</kw>
            <kw>standards development organization</kw>
            <kw>consortium</kw>
            <kw>industrial forum</kw>
        </keywords>
        <abstract><p>Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed.  The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052.  This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-liaison-guidelines-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4691</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4692</doc-id>
        <title>Considerations on the IPv6 Host Density Metric</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>ipv6 unicast address blocks</kw>
        </keywords>
        <abstract><p>This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks.  This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol.  Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-huston-hd-metric-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4692</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4693</doc-id>
        <title>IETF Operational Notes</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ION</kw>
        </keywords>
        <abstract><p>This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.</p><p> It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-alvestrand-ipod-03</draft>
        <obsoleted-by>
            <doc-id>RFC6393</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4693</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4694</doc-id>
        <title>Number Portability Parameters for the "tel" URI</title>
        <author>
            <name>J. Yu</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>np</kw>
        </keywords>
        <abstract><p>This document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information.  Those parameters can be passed to the next-hop network node after an NP database dip has been performed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-iptel-tel-np-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC4694</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4695</doc-id>
        <title>RTP Payload Format for MIDI</title>
        <author>
            <name>J. Lazzaro</name>
        </author>
        <author>
            <name>J. Wawrzynek</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>169</page-count>
        <keywords>
            <kw>asc</kw>
            <kw>content streaming</kw>
            <kw>DLS 2</kw>
            <kw>General MIDI</kw>
            <kw>MIDI</kw>
            <kw>MIDI file</kw>
            <kw>MIDI file streaming</kw>
            <kw>MIDI light control</kw>
            <kw>MIDI rendering</kw>
            <kw>MIDI ringtone</kw>
            <kw>MIDI streaming MIDI sequencer</kw>
            <kw>MIDI time code</kw>
            <kw>MIDI timecode</kw>
            <kw>MIDI Manufacturers Association</kw>
            <kw>MMA mpeg4-generic MPEG 4</kw>
            <kw>MPEG 4 Structured Audio</kw>
            <kw>MPEG 4 Synthetic Coding</kw>
            <kw>MTC</kw>
            <kw>musical notes</kw>
            <kw>network musical performance</kw>
            <kw>recovery journal</kw>
            <kw>Show Control</kw>
            <kw>sonification</kw>
            <kw>ringtone</kw>
            <kw>rtp-midi</kw>
            <kw>RTP</kw>
            <kw>RTP MIDI</kw>
            <kw>SMPTE time code</kw>
            <kw>SMPTE timecode</kw>
            <kw>Standard MIDI Files</kw>
            <kw>XMF</kw>
        </keywords>
        <abstract><p>This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language.  The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable.  The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming).  The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss.  Stream behavior, including the MIDI rendering method, may be customized during session setup.  The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-midi-format-15</draft>
        <obsoleted-by>
            <doc-id>RFC6295</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4695</errata-url>
        <doi>10.17487/RFC4695</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4696</doc-id>
        <title>An Implementation Guide for RTP MIDI</title>
        <author>
            <name>J. Lazzaro</name>
        </author>
        <author>
            <name>J. Wawrzynek</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>checkpoint packet</kw>
            <kw>checkpoint history</kw>
            <kw>guard packets</kw>
            <kw>jitter</kw>
            <kw>keep-alive packets</kw>
            <kw>MIDI</kw>
            <kw>musical telepresence</kw>
            <kw>network musical performance</kw>
            <kw>NMP</kw>
            <kw>receiving algorithm</kw>
            <kw>recovery journal</kw>
            <kw>recovery journal receiving structure</kw>
            <kw>recovery journal sending structure</kw>
            <kw>RTP</kw>
            <kw>RTP MIDI</kw>
            <kw>queuing MIDI</kw>
            <kw>sending algorithm</kw>
            <kw>sending MIDI</kw>
            <kw>telepresence</kw>
        </keywords>
        <abstract><p>This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format.  The memo presents its advice in the context of a network musical performance application.  In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room.  Underlying the performances are RTP MIDI sessions over unicast UDP.  Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail.  Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-midi-guidelines-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4696</errata-url>
        <doi>10.17487/RFC4696</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4697</doc-id>
        <title>Observed DNS Resolution Misbehavior</title>
        <author>
            <name>M. Larson</name>
        </author>
        <author>
            <name>P. Barber</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>tld</kw>
            <kw>top level domain</kw>
        </keywords>
        <abstract><p>This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers.  We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries.  The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-dnsop-bad-dns-res-06</draft>
        <updated-by>
            <doc-id>RFC9520</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0123</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC4697</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4698</doc-id>
        <title>IRIS: An Address Registry (areg) Type for the Internet Registry Information Service</title>
        <author>
            <name>E. Gunduz</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>S. Kerr</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>ip address</kw>
            <kw>autonomous system number</kw>
            <kw>internet protocol address</kw>
        </keywords>
        <abstract><p>This document describes an IRIS registry schema for IP address and Autonomous System Number 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 Internet Protocol address registries. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-crisp-iris-areg-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4698</errata-url>
        <doi>10.17487/RFC4698</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4699</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4700</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4701</doc-id>
        <title>A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)</title>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>A. Gustafsson</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>dns fqdn</kw>
            <kw>fully qualified domain name</kw>
        </keywords>
        <abstract><p>It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases.  Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise.  To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer.  This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dhcid-rr-13</draft>
        <updated-by>
            <doc-id>RFC5494</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4701</errata-url>
        <doi>10.17487/RFC4701</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4702</doc-id>
        <title>The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option</title>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>dhcpv4</kw>
            <kw>dns rr</kw>
        </keywords>
        <abstract><p>This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-fqdn-option-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4702</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4703</doc-id>
        <title>Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients</title>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>dynamic assignment</kw>
            <kw>dns</kw>
            <kw>dhcid dns rr</kw>
        </keywords>
        <abstract><p>The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names.  To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS.  This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-ddns-resolution-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4703</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4704</doc-id>
        <title>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option</title>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>dns rr</kw>
        </keywords>
        <abstract><p>This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-fqdn-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4704</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4705</doc-id>
        <title>GigaBeam High-Speed Radio Link Encryption</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>A. Corry</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>key management</kw>
            <kw>wifiber</kw>
            <kw>radio link</kw>
        </keywords>
        <abstract><p>This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products.  The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-housley-gigabeam-radio-link-encrypt-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4705</errata-url>
        <doi>10.17487/RFC4705</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4706</doc-id>
        <title>Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)</title>
        <author>
            <name>M. Morgenstern</name>
        </author>
        <author>
            <name>M. Dodge</name>
        </author>
        <author>
            <name>S. Baillie</name>
        </author>
        <author>
            <name>U. Bonollo</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>167</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>adsl2+</kw>
            <kw>ADSL2-LINE-TC-MIB</kw>
            <kw>ADSL2-LINE-MIB</kw>
        </keywords>
        <abstract><p>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 parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-adslmib-adsl2-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <doi>10.17487/RFC4706</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4707</doc-id>
        <title>Netnews Administration System (NAS)</title>
        <author>
            <name>P. Grau</name>
        </author>
        <author>
            <name>V. Heinau</name>
        </author>
        <author>
            <name>H. Schlichting</name>
        </author>
        <author>
            <name>R. Schuettler</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>news servers</kw>
            <kw>news administrator</kw>
            <kw>news reader</kw>
        </keywords>
        <abstract><p>The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.</p><p> The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.</p><p> NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS-compliant software. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-dfncis-netnews-admin-sys-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4707</errata-url>
        <doi>10.17487/RFC4707</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4708</doc-id>
        <title>CellML Media Type</title>
        <author>
            <name>A. Miller</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>media format</kw>
            <kw>mathematical model</kw>
            <kw>mathematical modelling</kw>
            <kw>mathematical modeling</kw>
            <kw>content MathML</kw>
            <kw>markup languages</kw>
            <kw>bioengineering</kw>
            <kw>biology</kw>
        </keywords>
        <abstract><p>This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-miller-media-type-cellml-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4708</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4709</doc-id>
        <title>Mounting Web Distributed Authoring and Versioning (WebDAV) Servers</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>drag-and-drop</kw>
        </keywords>
        <abstract><p>In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a Web Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.</p><p> This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-reschke-webdav-mount-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4709</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4710</doc-id>
        <title>Real-time Application Quality-of-Service Monitoring (RAQMON) Framework</title>
        <author>
            <name>A. Siddiqui</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>E. Golovinsky</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>end-devices</kw>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices.  This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP).  This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmonmib-raqmon-framework-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC4710</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4711</doc-id>
        <title>Real-time Application Quality-of-Service Monitoring (RAQMON) MIB</title>
        <author>
            <name>A. Siddiqui</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>E. Golovinsky</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>remote monitoring mib</kw>
            <kw>qos</kw>
            <kw>RAQMON-MIB</kw>
        </keywords>
        <abstract><p>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, RFC 2819.  In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmonmib-raqmon-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC4711</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4712</doc-id>
        <title>Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)</title>
        <author>
            <name>A. Siddiqui</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>E. Golovinsky</name>
        </author>
        <author>
            <name>M. Rahman</name>
        </author>
        <author>
            <name>Y. Kim</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>rds</kw>
            <kw>raqmon data source</kw>
            <kw>qos</kw>
            <kw>RAQMON-RDS-MIB</kw>
        </keywords>
        <abstract><p>This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmonmib-raqmon-pdu-14</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>rmonmib</wg_acronym>
        <doi>10.17487/RFC4712</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4713</doc-id>
        <title>Registration and Administration Recommendations for Chinese Domain Names</title>
        <author>
            <name>X. Lee</name>
        </author>
        <author>
            <name>W. Mao</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>N. Hsu</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>cdn</kw>
            <kw>sc</kw>
            <kw>simplified chinese</kw>
            <kw>tc</kw>
            <kw>traditional chinese</kw>
        </keywords>
        <abstract><p>Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms.  The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration.  This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names.  The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-xdlee-idn-cdnadmin-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4713</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4714</doc-id>
        <title>Requirements for IETF Technical Publication Service</title>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>S. Hayes</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>internet engineering task force</kw>
        </keywords>
        <abstract><p>The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation.  Technical publication is the process by which that output is disseminated to the community at large.  As such, it is important to understand the requirements on the publication process.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mankin-pub-req-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4714</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4715</doc-id>
        <title>The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI</title>
        <author>
            <name>M. Munakata</name>
        </author>
        <author>
            <name>S. Schubert</name>
        </author>
        <author>
            <name>T. Ohba</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>isup</kw>
            <kw>isdn user part</kw>
        </keywords>
        <abstract><p>Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases.  To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-munakata-iptel-isub-type-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4716</doc-id>
        <title>The Secure Shell (SSH) Public Key File Format</title>
        <author>
            <name>J. Galbraith</name>
        </author>
        <author>
            <name>R. Thayer</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations.</p><p> In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-secsh-publickeyfile-13</draft>
        <updated-by>
            <doc-id>RFC9519</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <doi>10.17487/RFC4716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4717</doc-id>
        <title>Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>J. Jayakumar</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>N. El-Aawar</name>
        </author>
        <author>
            <name>J. Brayley</name>
        </author>
        <author>
            <name>G. Koleyni</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>pw</kw>
            <kw>pseudowire</kw>
            <kw>multiprotocol label switching</kw>
        </keywords>
        <abstract><p>An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network.  This enables service providers to offer "emulated" ATM services over existing MPLS networks.  This document specifies methods for the encapsulation of ATM cells within a pseudowire.  It also specifies the procedures for using a PW to provide an ATM service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-atm-encap-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4717</errata-url>
        <doi>10.17487/RFC4717</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4718</doc-id>
        <title>IKEv2 Clarifications and Implementation Guidelines</title>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>internet key exchange</kw>
        </keywords>
        <abstract><p>This document clarifies many areas of the IKEv2 specification.  It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations.  The purpose of this document is to encourage the development of interoperable implementations.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-eronen-ipsec-ikev2-clarifications-09</draft>
        <obsoleted-by>
            <doc-id>RFC5996</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4718</errata-url>
        <doi>10.17487/RFC4718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4719</doc-id>
        <title>Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)</title>
        <author>
            <name>R. Aggarwal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Townsley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Dos Santos</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>port-to-port</kw>
            <kw>vlan</kw>
        </keywords>
        <abstract><p>This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3).  This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames.  The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-pwe3-ethernet-09</draft>
        <updated-by>
            <doc-id>RFC5641</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4719</errata-url>
        <doi>10.17487/RFC4719</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4720</doc-id>
        <title>Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>D. Allan</name>
        </author>
        <author>
            <name>N. Del Regno</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>fcs</kw>
        </keywords>
        <abstract><p>This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-fcs-retention-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC4720</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4721</doc-id>
        <title>Mobile IPv4 Challenge/Response Extensions (Revised)</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>J. Bharatia</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>chap</kw>
        </keywords>
        <abstract><p>Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices.</p><p> 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.</p><p> Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-rfc3012bis-05</draft>
        <obsoletes>
            <doc-id>RFC3012</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3344</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4721</errata-url>
        <doi>10.17487/RFC4721</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4722</doc-id>
        <title>Media Server Control Markup Language (MSCML) and Protocol</title>
        <author>
            <name>J. Van Dyke</name>
        </author>
        <author>
            <name>E. Burger</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Spitzer</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>ivr</kw>
            <kw>interactive voice response</kw>
        </keywords>
        <abstract><p>Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions.  MSCML presents an application-level control model, as opposed to device-level control models.  One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-vandyke-mscml-09</draft>
        <obsoleted-by>
            <doc-id>RFC5022</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4722</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4723</doc-id>
        <title>Registration of Media Type audio/mobile-xmf</title>
        <author>
            <name>T. Kosonen</name>
        </author>
        <author>
            <name>T. White</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mma</kw>
            <kw>midi manufacturers association</kw>
            <kw>association of musical electronices industry</kw>
            <kw>amei</kw>
            <kw>MIDI</kw>
            <kw>Musical Instrument Digital Interface</kw>
        </keywords>
        <abstract><p>The MIDI Manufacturers Association (MMA) and the Association of Musical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications.  Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration.  This document registers the media type audio/mobile-xmf.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kosonen-mobile-xmf-mediatype-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4723</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4724</doc-id>
        <title>Graceful Restart Mechanism for BGP</title>
        <author>
            <name>S. Sangli</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>R. Fernando</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>end-of-rib</kw>
            <kw>bgp restart</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.</p><p> The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-restart-13</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8538</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4724</errata-url>
        <doi>10.17487/RFC4724</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4725</doc-id>
        <title>ENUM Validation Architecture</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>E.164</kw>
            <kw>Registry</kw>
            <kw>Registrar</kw>
            <kw>Registrant</kw>
            <kw>Assignee</kw>
        </keywords>
        <abstract><p>An ENUM domain name is tightly coupled with the underlying E.164 number.  The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation".  This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-enum-validation-arch-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4725</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4726</doc-id>
        <title>A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>J.-P. Vasseur</name>
        </author>
        <author>
            <name>A. Ayyangar</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>mpls-te</kw>
            <kw>te</kw>
            <kw>lsp</kw>
            <kw>label switched path</kw>
        </keywords>
        <abstract><p>This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.</p><p> For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-inter-domain-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4726</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4727</doc-id>
        <title>Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>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.  This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-fenner-iana-exp-2780-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4727</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4728</doc-id>
        <title>The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4</title>
        <author>
            <name>D. Johnson</name>
        </author>
        <author>
            <name>Y. Hu</name>
        </author>
        <author>
            <name>D. Maltz</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>107</page-count>
        <keywords>
            <kw>route discovery</kw>
            <kw>route maintenance</kw>
        </keywords>
        <abstract><p>The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes.  DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration.  The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network.  All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use.  The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness.  Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change.  The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility.  This document specifies the operation of the DSR protocol for routing unicast IPv4 packets.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-manet-dsr-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4728</errata-url>
        <doi>10.17487/RFC4728</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4729</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for  the Near Field Communication (NFC) Forum</title>
        <author>
            <name>M. Abel</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>forum technical committee</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) resources published by the Near Field Communication (NFC) Forum.  The NFC Forum defines and manages resources that utilize this URN identification model.  Management activities for these and other resource types are provided by the NFC Forum Technical Committee.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-abel-nfc-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4730</doc-id>
        <title>A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)</title>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>M. Dolly</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>ua</kw>
            <kw>user agent</kw>
            <kw>dtmf</kw>
            <kw>dual tone multi-frequency</kw>
        </keywords>
        <abstract><p>This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML).  The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)".  The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA).  The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server.  The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-kpml-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4730</errata-url>
        <doi>10.17487/RFC4730</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4731</doc-id>
        <title>IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>D. Cridland</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>uid search</kw>
            <kw>uid</kw>
        </keywords>
        <abstract><p>This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned.  The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-imap-search-ret-03</draft>
        <updated-by>
            <doc-id>RFC9394</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4731</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4732</doc-id>
        <title>Internet Denial-of-Service Considerations</title>
        <author>
            <name>M. Handley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rescorla</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>dos</kw>
        </keywords>
        <abstract><p>This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems.  The aim is to encourage protocol designers and network engineers towards designs that are more robust.  We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-dos-05</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4732</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4733</doc-id>
        <title>RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>application</kw>
            <kw>protocol</kw>
            <kw>DTMF</kw>
            <kw>dual-tone</kw>
            <kw>multifrequency</kw>
        </keywords>
        <abstract><p>This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.</p><p> This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.</p><p> This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc2833bis-15</draft>
        <obsoletes>
            <doc-id>RFC2833</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4734</doc-id>
            <doc-id>RFC5244</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4733</errata-url>
        <doi>10.17487/RFC4733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4734</doc-id>
        <title>Definition of Events for Modem, Fax, and Text Telephony Signals</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>real-time</kw>
            <kw>application</kw>
            <kw>protocol</kw>
            <kw>DTMF</kw>
            <kw>dual-tone</kw>
            <kw>multifrequency</kw>
        </keywords>
        <abstract><p>This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload.  It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc2833bisdata-08</draft>
        <obsoletes>
            <doc-id>RFC2833</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4733</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4734</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4735</doc-id>
        <title>Example Media Types for Use in Documentation</title>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>media type</kw>
            <kw>example</kw>
        </keywords>
        <abstract><p>This document is registration for the 'example' media type and 'example' subtypes within the standards tree.  The 'example/*' and '*/example' media types are defined for documentation purposes only. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-taylor-types-example-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4735</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4736</doc-id>
        <title>Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ikejiri</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>rsvp-te</kw>
            <kw>te lsp path</kw>
        </keywords>
        <abstract><p>This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE).  This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path).  The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-loose-path-reopt-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4737</doc-id>
        <title>Packet Reordering Metrics</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>L. Ciavattone</name>
        </author>
        <author>
            <name>G. Ramachandran</name>
        </author>
        <author>
            <name>S. Shalunov</name>
        </author>
        <author>
            <name>J. Perser</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>ippm</kw>
        </keywords>
        <abstract><p>This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis.  It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics.  The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design.  Additional metrics quantify the frequency of reordering and the distance between separate occurrences.  We then define a metric oriented toward assessment of reordering effects on TCP.  Several examples of evaluation using the various sample metrics are included.  An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-reordering-13</draft>
        <updated-by>
            <doc-id>RFC6248</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC4737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4738</doc-id>
        <title>MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>D. Ignjatic</name>
        </author>
        <author>
            <name>L. Dondeti</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <author>
            <name>P. Lin</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MIKEY</kw>
            <kw>SRTP</kw>
            <kw>key management</kw>
            <kw>group key distribution</kw>
            <kw>RSA-R</kw>
        </keywords>
        <abstract><p>The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange.  In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder.  In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance.  We propose a new MIKEY mode that works well in such scenarios.  This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members).  This document updates RFC 3830 with the RSA-R mode. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-mikey-rsa-r-07</draft>
        <updates>
            <doc-id>RFC3830</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC4738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4739</doc-id>
        <title>Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol</title>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods.  Currently, each endpoint uses only one of these mechanisms to authenticate itself.  This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism.  This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user.  When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-eronen-ipsec-ikev2-multiple-auth-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4740</doc-id>
        <title>Diameter Session Initiation Protocol (SIP) Application</title>
        <author>
            <name>M. Garcia-Martin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Belinchon</name>
        </author>
        <author>
            <name>M. Pallares-Lopez</name>
        </author>
        <author>
            <name>C. Canales-Valenzuela</name>
        </author>
        <author>
            <name>K. Tammi</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>diameter client</kw>
        </keywords>
        <abstract><p>This document specifies the Diameter Session Initiation Protocol (SIP) application.  This is a Diameter application that allows a Diameter client to request authentication and authorization information.  This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-aaa-diameter-sip-app-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>aaa</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4740</errata-url>
        <doi>10.17487/RFC4740</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4741</doc-id>
        <title>NETCONF Configuration Protocol</title>
        <author>
            <name>R. Enns</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>network configuration protocol</kw>
            <kw>network device</kw>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>rpc</kw>
            <kw>remote procedure call</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-prot-12</draft>
        <obsoleted-by>
            <doc-id>RFC6241</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4741</errata-url>
        <doi>10.17487/RFC4741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4742</doc-id>
        <title>Using the NETCONF Configuration Protocol over Secure SHell (SSH)</title>
        <author>
            <name>M. Wasserman</name>
        </author>
        <author>
            <name>T. Goddard</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>network configuration protocol</kw>
        </keywords>
        <abstract><p>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-ssh-06</draft>
        <obsoleted-by>
            <doc-id>RFC6242</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4742</errata-url>
        <doi>10.17487/RFC4742</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4743</doc-id>
        <title>Using NETCONF over the Simple Object Access Protocol (SOAP)</title>
        <author>
            <name>T. Goddard</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>XMLCONF</kw>
            <kw>SOAP</kw>
            <kw>device managment</kw>
            <kw>XML</kw>
            <kw>Extensible Markup Language</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments.  Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP).  NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems.  Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-soap-08</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4743</errata-url>
        <doi>10.17487/RFC4743</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4744</doc-id>
        <title>Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>K. Crozier</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>Configuration</kw>
            <kw>Network Management</kw>
            <kw>Extensible Markup Language</kw>
        </keywords>
        <abstract><p>This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-beep-10</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC4744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4745</doc-id>
        <title>Common Policy: A Document Format for Expressing Privacy Preferences</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <author>
            <name>J. Cuellar</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>rules</kw>
            <kw>conditions</kw>
            <kw>permissions</kw>
        </keywords>
        <abstract><p>This document defines a framework for authorization policies controlling access to application-specific data.  This framework combines common location- and presence-specific authorization aspects.  An XML schema specifies the language in which common policy rules are represented.  The common policy framework can be extended to other application domains. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-common-policy-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4745</errata-url>
        <doi>10.17487/RFC4745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4746</doc-id>
        <title>Extensible Authentication Protocol (EAP) Password Authenticated Exchange</title>
        <author>
            <name>T. Clancy</name>
        </author>
        <author>
            <name>W. Arbaugh</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>EAP-PAX</kw>
            <kw>password authenticated exchange</kw>
            <kw>key exchange</kw>
        </keywords>
        <abstract><p>This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange).  This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-clancy-eap-pax-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4746</errata-url>
        <doi>10.17487/RFC4746</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4747</doc-id>
        <title>The Virtual Fabrics MIB</title>
        <author>
            <name>S. Kipp</name>
        </author>
        <author>
            <name>G. Ramkumar</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-VIRTUAL-FABRIC-MIB</kw>
            <kw>fibre channel network</kw>
            <kw>virtual fabric</kw>
        </keywords>
        <abstract><p>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 network's Virtual Fabrics function. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-vf-mib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4747</errata-url>
        <doi>10.17487/RFC4747</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4748</doc-id>
        <title>RFC 3978 Update to Recognize the IETF Trust</title>
        <author>
            <name>S. Bradner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>ipr</kw>
            <kw>intellectual property rights</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights.</p><p> This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ipr-ietf-trust-update-03</draft>
        <obsoleted-by>
            <doc-id>RFC5378</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3978</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <doi>10.17487/RFC4748</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4749</doc-id>
        <title>RTP Payload Format for the G.729.1 Audio Codec</title>
        <author>
            <name>A. Sollaud</name>
        </author>
        <date>
            <month>October</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>itu-t</kw>
            <kw>international telecommunication union</kw>
        </keywords>
        <abstract><p>This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec.  A media type registration is included for this payload format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-g729-scal-wb-ext-07</draft>
        <updated-by>
            <doc-id>RFC5459</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4750</doc-id>
        <title>OSPF Version 2 Management Information Base</title>
        <author>
            <name>D. Joyal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Galecki</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Giacalone</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>121</page-count>
        <keywords>
            <kw>OSPF-MIB</kw>
            <kw>Open Shortest Path First</kw>
            <kw>SPF</kw>
            <kw>MIB</kw>
            <kw>routing</kw>
            <kw>network management mib</kw>
            <kw>OSPF-MIB</kw>
            <kw>OSPF-TRAP-MIB</kw>
        </keywords>
        <abstract><p>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 version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family.</p><p> This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-mib-update-11</draft>
        <obsoletes>
            <doc-id>RFC1850</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4750</errata-url>
        <doi>10.17487/RFC4750</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4751</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4752</doc-id>
        <title>The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SASL</kw>
            <kw>encryption</kw>
            <kw>protocol</kw>
            <kw>specific</kw>
        </keywords>
        <abstract><p>The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.</p><p> This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sasl-gssapi-08</draft>
        <obsoletes>
            <doc-id>RFC2222</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4752</errata-url>
        <doi>10.17487/RFC4752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4753</doc-id>
        <title>ECP Groups For IKE and IKEv2</title>
        <author>
            <name>D. Fu</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>elliptic curve</kw>
            <kw>Diffie-Hellman</kw>
            <kw>suite b</kw>
            <kw>nist curve</kw>
        </keywords>
        <abstract><p>This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.  Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic.  These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards.  In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipsec-ike-ecp-groups-03</draft>
        <obsoleted-by>
            <doc-id>RFC5903</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4753</errata-url>
        <doi>10.17487/RFC4753</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4754</doc-id>
        <title>IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
        <author>
            <name>D. Fu</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>suite b</kw>
        </keywords>
        <abstract><p>This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols.  ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods.  This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsec-ike-auth-ecdsa-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4754</errata-url>
        <doi>10.17487/RFC4754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4755</doc-id>
        <title>IP over InfiniBand: Connected Mode</title>
        <author>
            <name>V. Kashyap</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipoib-connected-mode-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipoib</wg_acronym>
        <doi>10.17487/RFC4755</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4756</doc-id>
        <title>Forward Error Correction Grouping Semantics in Session Description Protocol</title>
        <author>
            <name>A. Li</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>fec</kw>
            <kw>sdp</kw>
            <kw>media lines</kw>
        </keywords>
        <abstract><p>This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP).  The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-fec-grouping-05</draft>
        <obsoleted-by>
            <doc-id>RFC5956</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4756</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4757</doc-id>
        <title>The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows</title>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>J. Brezak</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>md5 hmac</kw>
        </keywords>
        <abstract><p>The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.</p><p> The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-jaganathan-rc4-hmac-03</draft>
        <updated-by>
            <doc-id>RFC6649</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4757</errata-url>
        <doi>10.17487/RFC4757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4758</doc-id>
        <title>Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1</title>
        <author>
            <name>M. Nystroem</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>rsa laboratories</kw>
            <kw>one-time password specifications</kw>
            <kw>otps</kw>
        </keywords>
        <abstract><p>This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.</p><p> CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-nystrom-ct-kip-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4758</errata-url>
        <doi>10.17487/RFC4758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4759</doc-id>
        <title>The ENUM Dip Indicator Parameter for the "tel" URI</title>
        <author>
            <name>R. Stastny</name>
        </author>
        <author>
            <name>R. Shockey</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>E.164</kw>
            <kw>telephone number</kw>
        </keywords>
        <abstract><p>This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements.  A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter.  The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element.  Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-iptel-tel-enumdi-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC4759</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4760</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>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MEXT-BGP4</kw>
            <kw>border gateway protocol</kw>
            <kw>network layer protocols</kw>
        </keywords>
        <abstract><p>This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, 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]</p></abstract>
        <draft>draft-ietf-idr-rfc2858bis-10</draft>
        <obsoletes>
            <doc-id>RFC2858</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7606</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4760</errata-url>
        <doi>10.17487/RFC4760</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4761</doc-id>
        <title>Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling</title>
        <author>
            <name>K. Kompella</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>transparent lan service</kw>
            <kw>virtual private switched network</kw>
            <kw>service provider</kw>
        </keywords>
        <abstract><p>Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.</p><p> This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-bgp-08</draft>
        <updated-by>
            <doc-id>RFC5462</doc-id>
            <doc-id>RFC8395</doc-id>
            <doc-id>RFC8614</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC4761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4762</doc-id>
        <title>Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling</title>
        <author>
            <name>M. Lasserre</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Kompella</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>land area network</kw>
            <kw>transparent lan service</kw>
        </keywords>
        <abstract><p>This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.</p><p> This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-ldp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4762</errata-url>
        <doi>10.17487/RFC4762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4763</doc-id>
        <title>Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)</title>
        <author>
            <name>M. Vanderveen</name>
        </author>
        <author>
            <name>H. Soliman</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>IEEE 802.11i</kw>
            <kw>user anonymity</kw>
        </keywords>
        <abstract><p>This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE).  This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748.  The specification has passed Designated Expert review for this IANA assignment.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-vanderveen-eap-sake-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4763</errata-url>
        <doi>10.17487/RFC4763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4764</doc-id>
        <title>The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method</title>
        <author>
            <name>F. Bersani</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>pre-shared key</kw>
        </keywords>
        <abstract><p>This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK).  EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over.  This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes.  EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-bersani-eap-psk-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4764</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4765</doc-id>
        <title>The Intrusion Detection Message Exchange Format (IDMEF)</title>
        <author>
            <name>H. Debar</name>
        </author>
        <author>
            <name>D. Curry</name>
        </author>
        <author>
            <name>B. Feinstein</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>157</page-count>
        <keywords>
            <kw>intrusion detection</kw>
            <kw>security</kw>
            <kw>secure</kw>
            <kw>exchange</kw>
            <kw>intrusion</kw>
            <kw>IDS</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.</p><p> This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-idwg-idmef-xml-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>idwg</wg_acronym>
        <doi>10.17487/RFC4765</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4766</doc-id>
        <title>Intrusion Detection Message Exchange Requirements</title>
        <author>
            <name>M. Wood</name>
        </author>
        <author>
            <name>M. Erlinger</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>idmef</kw>
            <kw>idwg</kw>
            <kw>intrusion detection exchange format</kw>
        </keywords>
        <abstract><p>The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.  This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed.  Scenarios are used to illustrate some requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idwg-requirements-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>idwg</wg_acronym>
        <doi>10.17487/RFC4766</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4767</doc-id>
        <title>The Intrusion Detection Exchange Protocol (IDXP)</title>
        <author>
            <name>B. Feinstein</name>
        </author>
        <author>
            <name>G. Matthews</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>intrusion</kw>
            <kw>intrusion detection</kw>
            <kw>beep</kw>
            <kw>security</kw>
            <kw>ids</kw>
            <kw>security protocol</kw>
            <kw>secure protocol</kw>
            <kw>secure exchange</kw>
            <kw>idmef</kw>
        </keywords>
        <abstract><p>This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities.  IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol.  The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data.  The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-idwg-beep-idxp-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>idwg</wg_acronym>
        <doi>10.17487/RFC4767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4768</doc-id>
        <title>Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>acl</kw>
            <kw>access control list</kw>
        </keywords>
        <abstract><p>The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization.  GSS-API authenticates two named parties to each other.  Names can be stored on access control lists (ACLs) to make authorization decisions.  Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API.  As people move within an organization or change their names, the name authenticated by GSS-API may change.  Using some sort of constant identifier would make ACLs more stable.  Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments.  Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication.  This document motivates extensions to GSS-API naming and describes the extensions under discussion.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-kitten-gss-naming-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC4768</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4769</doc-id>
        <title>IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information</title>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>R. Shockey</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>tel</kw>
            <kw>uri</kw>
            <kw>uri scheme</kw>
            <kw>sip</kw>
        </keywords>
        <abstract><p>This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761.  This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-pstn-05</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4770</doc-id>
        <title>vCard Extensions for Instant Messaging (IM)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>impp</kw>
            <kw>instant messaging and presence protocol</kw>
        </keywords>
        <abstract><p>This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications.  IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books.  It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-jennings-impp-vcard-08</draft>
        <obsoleted-by>
            <doc-id>RFC6350</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4770</errata-url>
        <doi>10.17487/RFC4770</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4771</doc-id>
        <title>Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)</title>
        <author>
            <name>V. Lehtovirta</name>
        </author>
        <author>
            <name>M. Naslund</name>
        </author>
        <author>
            <name>K. Norrman</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>roc</kw>
        </keywords>
        <abstract><p>This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag.  The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize.  The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-lehtovirta-srtp-rcc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4771</errata-url>
        <doi>10.17487/RFC4771</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4772</doc-id>
        <title>Security Implications of Using the Data Encryption Standard (DES)</title>
        <author>
            <name>S. Kelly</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary.  As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES).  Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications.  While this is not always inappropriate, it frequently is.  This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kelly-saag-des-implications-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4772</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4773</doc-id>
        <title>Administration of the IANA Special Purpose IPv6 Address Block</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-huston-ipv6-iana-specials-01</draft>
        <obsoleted-by>
            <doc-id>RFC6890</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4773</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4774</doc-id>
        <title>Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168.  This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics.  This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-alternates-02</draft>
        <updated-by>
            <doc-id>RFC6040</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0124</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4774</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4775</doc-id>
        <title>Procedures for Protocol Extensions and Variations</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>sdo</kw>
            <kw>standards development organization</kw>
        </keywords>
        <abstract><p>This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.</p><p> This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-carpenter-protocol-extensions-04</draft>
        <is-also>
            <doc-id>BCP0125</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4776</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>lci</kw>
            <kw>local configuration information</kw>
        </keywords>
        <abstract><p>This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server.  The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information.  The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC4676</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5774</doc-id>
            <doc-id>RFC6848</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC4776</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4777</doc-id>
        <title>IBM's iSeries Telnet Enhancements</title>
        <author>
            <name>T. Murphy Jr.</name>
        </author>
        <author>
            <name>P. Rieth</name>
        </author>
        <author>
            <name>J. Stevens</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>midrange business computer</kw>
            <kw>telnet environment</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>printer</kw>
        </keywords>
        <abstract><p>This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.</p><p> These support functions are implemented primarily using the Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-murphy-iser-telnet-04</draft>
        <obsoletes>
            <doc-id>RFC2877</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4777</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4778</doc-id>
        <title>Operational Security Current Practices in Internet Service Provider Environments</title>
        <author>
            <name>M. Kaeo</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>isp</kw>
        </keywords>
        <abstract><p>This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices.  The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-opsec-current-practices-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4778</errata-url>
        <doi>10.17487/RFC4778</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4779</doc-id>
        <title>ISP IPv6 Deployment Scenarios in Broadband Access Networks</title>
        <author>
            <name>S. Asadullah</name>
        </author>
        <author>
            <name>A. Ahmed</name>
        </author>
        <author>
            <name>C. Popoviciu</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>J. Palet</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>v6ops</kw>
            <kw>isp</kw>
            <kw>ipv6</kw>
            <kw>deployment</kw>
            <kw>scenarios</kw>
            <kw>broadband</kw>
            <kw>networks</kw>
        </keywords>
        <abstract><p>This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today\'s Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services.  Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document.  The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness.  In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-bb-deployment-scenarios-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4779</errata-url>
        <doi>10.17487/RFC4779</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4780</doc-id>
        <title>Management Information Base for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>K. Lingle</name>
        </author>
        <author>
            <name>J-F. Mule</name>
        </author>
        <author>
            <name>J. Maeng</name>
        </author>
        <author>
            <name>D. Walker</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>registrar services</kw>
            <kw>SIP-COMMON-MIB</kw>
            <kw>SIP-TC-MIB</kw>
            <kw>SIP-UA-MIB DEFINITIONS</kw>
            <kw>SIP-SERVER-MIB</kw>
        </keywords>
        <abstract><p>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 manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4780</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4781</doc-id>
        <title>Graceful Restart Mechanism for BGP with MPLS</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>multiprotocol label switching</kw>
            <kw>nlri</kw>
            <kw>bgp network layer reachability information</kw>
        </keywords>
        <abstract><p>A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.</p><p> The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-bgp-mpls-restart-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4781</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4782</doc-id>
        <title>Quick-Start for TCP and IP</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>A. Jain</name>
        </author>
        <author>
            <name>P. Sarolahti</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.</p><p> This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-quickstart-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4782</errata-url>
        <doi>10.17487/RFC4782</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4783</doc-id>
        <title>GMPLS - Communication of Alarm Information</title>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>generalized multiprotocol label switching</kw>
            <kw>gmpls-rsvp</kw>
        </keywords>
        <abstract><p>This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.</p><p> This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-alarm-spec-06</draft>
        <updates>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4783</errata-url>
        <doi>10.17487/RFC4783</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4784</doc-id>
        <title>Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks</title>
        <author>
            <name>C. Carroll</name>
        </author>
        <author>
            <name>F. Quick</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>mip</kw>
            <kw>cryptographic keys</kw>
            <kw>dmu</kw>
        </keywords>
        <abstract><p>The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).</p><p> cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.</p></abstract>
        <draft>draft-carroll-dynmobileip-cdma-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4784</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4785</doc-id>
        <title>Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)</title>
        <author>
            <name>U. Blumenthal</name>
        </author>
        <author>
            <name>P. Goel</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>cipher suite</kw>
        </keywords>
        <abstract><p>This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol.  These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-psk-null-03</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC4785</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4786</doc-id>
        <title>Operation of Anycast Services</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>K. Lindqvist</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>ROUTING</kw>
            <kw>LOAD-BALANCING</kw>
            <kw>LOAD-SHARING</kw>
        </keywords>
        <abstract><p>As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.</p><p> Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-grow-anycast-04</draft>
        <is-also>
            <doc-id>BCP0126</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC4786</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4787</doc-id>
        <title>Network Address Translation (NAT) Behavioral Requirements for Unicast UDP</title>
        <author>
            <name>F. Audet</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>nat</kw>
            <kw>sip</kw>
            <kw>udp</kw>
        </keywords>
        <abstract><p>This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently.  Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-behave-nat-udp-08</draft>
        <updated-by>
            <doc-id>RFC6888</doc-id>
            <doc-id>RFC7857</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0127</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC4787</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4788</doc-id>
        <title>Enhancements to RTP Payload Formats for EVRC Family Codecs</title>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>R. Kapoor</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>enhanced variable rate codec</kw>
            <kw>real time transmission protocol</kw>
            <kw>evrc-b</kw>
            <kw>dtx</kw>
            <kw>discontinuous transmission</kw>
        </keywords>
        <abstract><p>This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions.  In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP.  Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-compact-bundled-evrc-11</draft>
        <updates>
            <doc-id>RFC3558</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5188</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4788</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4789</doc-id>
        <title>Simple Network Management Protocol (SNMP) over IEEE 802 Networks</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>T. Jeffree</name>
        </author>
        <date>
            <month>November</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.</p><p> This document obsoletes RFC 1089. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-schoenw-snmp-ether-02</draft>
        <obsoletes>
            <doc-id>RFC1089</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3417</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4790</doc-id>
        <title>Internet Application Protocol Collation Registry</title>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>M. Duerst</name>
        </author>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>collation</kw>
            <kw>sorting</kw>
        </keywords>
        <abstract><p>Many Internet application protocols include string-based lookup, searching, or sorting operations.  However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF).  Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-newman-i18n-comparator-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4790</errata-url>
        <doi>10.17487/RFC4790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4791</doc-id>
        <title>Calendaring Extensions to WebDAV (CalDAV)</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>B. Desruisseaux</name>
        </author>
        <author>
            <name>L. Dusseault</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>107</page-count>
        <keywords>
            <kw>calsched</kw>
            <kw>calsch</kw>
            <kw>calcav</kw>
            <kw>calendar</kw>
            <kw>calendaring</kw>
            <kw>scheduling</kw>
            <kw>webdav</kw>
            <kw>ical</kw>
            <kw>icalendar</kw>
            <kw>itip</kw>
            <kw>text/calendar</kw>
            <kw>http</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format.  This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-dusseault-caldav-15</draft>
        <updated-by>
            <doc-id>RFC5689</doc-id>
            <doc-id>RFC6638</doc-id>
            <doc-id>RFC6764</doc-id>
            <doc-id>RFC7809</doc-id>
            <doc-id>RFC7953</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4791</errata-url>
        <doi>10.17487/RFC4791</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4792</doc-id>
        <title>Encoding Instructions for the Generic String Encoding Rules (GSER)</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ASN.1</kw>
        </keywords>
        <abstract><p>Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules.  This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-legg-ldap-gser-ei-02</draft>
        <updates>
            <doc-id>RFC3641</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4793</doc-id>
        <title>The EAP Protected One-Time Password Protocol (EAP-POTP)</title>
        <author>
            <name>M. Nystroem</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>otp</kw>
            <kw>extensible authentication protocol</kw>
        </keywords>
        <abstract><p>This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients.  The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-nystrom-eap-potp-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4794</doc-id>
        <title>RFC 1264 Is Obsolete</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <date>
            <month>December</month>
            <year>2006</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>RFC 1264 was written during what was effectively a completely different time in the life of the Internet.  It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties.  In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-fenner-obsolete-1264-03</draft>
        <obsoletes>
            <doc-id>RFC1264</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4795</doc-id>
        <title>Link-local Multicast Name Resolution (LLMNR)</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>L. Esibov</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible.  LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache.  Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsext-mdns-47</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4795</errata-url>
        <doi>10.17487/RFC4795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4796</doc-id>
        <title>The Session Description Protocol (SDP) Content Attribute</title>
        <author>
            <name>J. Hautakorpi</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>media attribute</kw>
            <kw>content</kw>
        </keywords>
        <abstract><p>This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'.  The 'content' attribute defines the content of the media stream to a more detailed level than the media description line.  The sender of an SDP session description can attach the 'content' attribute to one or more media streams.  The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-media-content-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC4796</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4797</doc-id>
        <title>Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>January</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>L3VPN GRE encapsulation</kw>
        </keywords>
        <abstract><p>This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).</p><p> The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l3vpn-gre-ip-2547-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC4797</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4798</doc-id>
        <title>Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)</title>
        <author>
            <name>J. De Clercq</name>
        </author>
        <author>
            <name>D. Ooms</name>
        </author>
        <author>
            <name>S. Prevost</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>mp-bgp</kw>
        </keywords>
        <abstract><p>This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud.  This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS.  The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4.  In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ooms-v6ops-bgp-tunnel-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC4798</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4799</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4800</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4801</doc-id>
        <title>Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>GMPLS-TC-STD-MIB</kw>
        </keywords>
        <abstract><p>This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information.  The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-tc-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4801</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4802</doc-id>
        <title>Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>GMPLS-TE-STD-MIB</kw>
            <kw>IANA-GMPLS-TC-MIB</kw>
        </keywords>
        <abstract><p>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 Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-te-mib-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4802</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4803</doc-id>
        <title>Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>GMPLS-LSR-STD-MIB</kw>
            <kw>GMPLS-LABEL-STD-MIB</kw>
        </keywords>
        <abstract><p>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 to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-lsr-mib-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4803</errata-url>
        <doi>10.17487/RFC4803</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4804</doc-id>
        <title>Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels</title>
        <author>
            <name>F. Le Faucheur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>traffic engineering</kw>
            <kw>diffserv-aware mpls traffic engineering</kw>
        </keywords>
        <abstract><p>RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations.  This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels.  This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations.  This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-dste-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4804</errata-url>
        <doi>10.17487/RFC4804</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4805</doc-id>
        <title>Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types</title>
        <author>
            <name>O. Nicklass</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>DS1-MIB</kw>
        </keywords>
        <abstract><p>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, J1, 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.</p><p> This document obsoletes RFC 3895. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-orly-atommib-rfc3895bis-01</draft>
        <obsoletes>
            <doc-id>RFC3895</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4805</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4806</doc-id>
        <title>Online Certificate Status Protocol (OCSP) Extensions to IKEv2</title>
        <author>
            <name>M. Myers</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet key exchange version 2</kw>
        </keywords>
        <abstract><p>While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.</p><p> When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-myers-ikev2-ocsp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4806</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4807</doc-id>
        <title>IPsec Security Policy Database Configuration MIB</title>
        <author>
            <name>M. Baer</name>
        </author>
        <author>
            <name>R. Charlet</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>R. Story</name>
        </author>
        <author>
            <name>C. Wang</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>IPSEC-SPD-MIB</kw>
        </keywords>
        <abstract><p>This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol.  The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall.  This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsp-spd-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4807</errata-url>
        <doi>10.17487/RFC4807</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4808</doc-id>
        <title>Key Change Strategies for TCP-MD5</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>bgp</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>The TCP-MD5 option is most commonly used to secure BGP sessions between routers.  However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations.  We describe single-ended strategies that will permit (mostly) unsynchronized key changes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-bellovin-keyroll2385-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4808</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4809</doc-id>
        <title>Requirements for an IPsec Certificate Management Profile</title>
        <author>
            <name>C. Bonatti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Turner</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Lebovitz</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>internet protocol security</kw>
        </keywords>
        <abstract><p>This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems.  These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments.  It is intended that a standards track profile of a management protocol will be created to address many of these requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pki4ipsec-mgmt-profile-rqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pki4ipsec</wg_acronym>
        <doi>10.17487/RFC4809</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4810</doc-id>
        <title>Long-Term Archive Service Requirements</title>
        <author>
            <name>C. Wallace</name>
        </author>
        <author>
            <name>U. Pordesch</name>
        </author>
        <author>
            <name>R. Brandner</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>data integrity</kw>
            <kw>digital signatures</kw>
        </keywords>
        <abstract><p>There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time.  Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature.  This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ltans-reqs-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ltans</wg_acronym>
        <doi>10.17487/RFC4810</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4811</doc-id>
        <title>OSPF Out-of-Band Link State Database (LSDB) Resynchronization</title>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.</p><p> This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-nguyen-ospf-oob-resync-06</draft>
        <updated-by>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4811</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4812</doc-id>
        <title>OSPF Restart Signaling</title>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.</p><p> This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-nguyen-ospf-restart-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4812</errata-url>
        <doi>10.17487/RFC4812</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4813</doc-id>
        <title>OSPF Link-Local Signaling</title>
        <author>
            <name>B. Friedman</name>
        </author>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>D. Yeung</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>OSPF is a link-state intra-domain routing protocol used in IP networks.  OSPF routers exchange information on a link using packets that follow a well-defined format.  The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations.  This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-nguyen-ospf-lls-06</draft>
        <obsoleted-by>
            <doc-id>RFC5613</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4813</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4814</doc-id>
        <title>Hash and Stuffing: Overlooked Factors in Network Device Benchmarking</title>
        <author>
            <name>D. Newman</name>
        </author>
        <author>
            <name>T. Player</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>bmwg</kw>
            <kw>benchmarking</kw>
            <kw>testing</kw>
            <kw>bit-stuffing</kw>
            <kw>byte-stuffing</kw>
        </keywords>
        <abstract><p>Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation.  However, current benchmarking practice overlooks two factors that have a profound impact on test results.  First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results.  Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results.  This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-hash-stuffing-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4814</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4815</doc-id>
        <title>RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>K. Sandlund</name>
        </author>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>P. Kremer</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>ip</kw>
            <kw>udp</kw>
            <kw>user datagram protocol</kw>
            <kw>rtp</kw>
            <kw>realtime transport protocol</kw>
            <kw>esp</kw>
            <kw>encapsulation security payload</kw>
        </keywords>
        <abstract><p>RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload).  Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations.  This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095.  In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-rtp-impl-guide-22</draft>
        <updates>
            <doc-id>RFC3095</doc-id>
            <doc-id>RFC3241</doc-id>
            <doc-id>RFC3843</doc-id>
            <doc-id>RFC4019</doc-id>
            <doc-id>RFC4362</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4815</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4816</doc-id>
        <title>Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>J. Brayley</name>
        </author>
        <author>
            <name>T. Walsh</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-cell-transport-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC4816</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4817</doc-id>
        <title>Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3</title>
        <author>
            <name>M. Townsley</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>S. Wainner</name>
        </author>
        <author>
            <name>T. Seely</name>
        </author>
        <author>
            <name>J. Young</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>l2tpv3</kw>
            <kw>multiprotocol label switching label stack</kw>
            <kw>label stack</kw>
        </keywords>
        <abstract><p>The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks.  This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation.  This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-over-l2tpv3-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4817</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4818</doc-id>
        <title>RADIUS Delegated-IPv6-Prefix Attribute</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>remote authentication dial in user service</kw>
            <kw>diameter</kw>
        </keywords>
        <abstract><p>This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user.  This attribute is usable within either RADIUS or Diameter. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-delegated-prefix-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC4818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4819</doc-id>
        <title>Secure Shell Public Key Subsystem</title>
        <author>
            <name>J. Galbraith</name>
        </author>
        <author>
            <name>J. Van Dyke</name>
        </author>
        <author>
            <name>J. Bright</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ssh</kw>
            <kw>ssh2</kw>
        </keywords>
        <abstract><p>Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.</p><p> The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.</p><p> A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-secsh-publickey-subsystem-08</draft>
        <updated-by>
            <doc-id>RFC9519</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secsh</wg_acronym>
        <doi>10.17487/RFC4819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4820</doc-id>
        <title>Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>P. Lei</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a padding chunk and a padding parameter and describes the required receiver side procedures.  The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size.  The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-padding-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4820</errata-url>
        <doi>10.17487/RFC4820</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4821</doc-id>
        <title>Packetization Layer Path MTU Discovery</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>J. Heffner</name>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>maximum transmission unit</kw>
            <kw>pmtud</kw>
        </keywords>
        <abstract><p>This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets.  This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pmtud-method-11</draft>
        <updated-by>
            <doc-id>RFC8899</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pmtud</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4821</errata-url>
        <doi>10.17487/RFC4821</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4822</doc-id>
        <title>RIPv2 Cryptographic Authentication</title>
        <author>
            <name>R. Atkinson</name>
        </author>
        <author>
            <name>M. Fanto</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>RIP2-MD5</kw>
            <kw>Routing Information Protocol</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082.  This document obsoletes RFC 2082 and updates RFC 2453.  This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5.  Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-rja-ripv2-auth-06</draft>
        <obsoletes>
            <doc-id>RFC2082</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2453</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4822</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4823</doc-id>
        <title>FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet</title>
        <author>
            <name>T. Harding</name>
        </author>
        <author>
            <name>R. Scott</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>applicability statement</kw>
            <kw>as</kw>
            <kw>business-to-business</kw>
        </keywords>
        <abstract><p>This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types.  Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts.  Authenticated acknowledgements employ multipart/signed replies to the original message.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ediint-as3-04</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ediint</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4823</errata-url>
        <doi>10.17487/RFC4823</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4824</doc-id>
        <title>The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)</title>
        <author>
            <name>J. Hofmueller</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Bachmann</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IO. zmoelnig</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>april fools</kw>
        </keywords>
        <abstract><p>This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).  This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4824</errata-url>
        <doi>10.17487/RFC4824</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4825</doc-id>
        <title>The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>xml</kw>
            <kw>http</kw>
            <kw>rest</kw>
            <kw>buddy list</kw>
            <kw>simple</kw>
            <kw>presence</kw>
            <kw>data manipulation</kw>
        </keywords>
        <abstract><p>This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP).  XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server.  XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-xcap-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC4825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4826</doc-id>
        <title>Extensible Markup Language (XML) Formats for Representing Resource Lists</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>http</kw>
            <kw>sip</kw>
            <kw>xml</kw>
            <kw>rest</kw>
            <kw>buddy list</kw>
            <kw>simple</kw>
            <kw>presence</kw>
            <kw>data manipulation</kw>
        </keywords>
        <abstract><p>In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users.  One example is a resource list service.  If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender.  To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents.  One document contains service URIs, along with their service definition and a reference to the associated group of users.  The second document contains the user lists that are referenced from the first.  This list of users can be utilized by other applications and services.  Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-xcap-list-usage-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4826</errata-url>
        <doi>10.17487/RFC4826</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4827</doc-id>
        <title>An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents</title>
        <author>
            <name>M. Isomaki</name>
        </author>
        <author>
            <name>E. Leppanen</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PIDF</kw>
            <kw>AUID</kw>
            <kw>hard state</kw>
            <kw>PUBLISH</kw>
            <kw>SIP Presence</kw>
            <kw>SIMPLE</kw>
            <kw>pidf-manipulation</kw>
            <kw>XCAP application usage</kw>
        </keywords>
        <abstract><p>This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents.  It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-xcap-pidf-manipulation-usage-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4827</errata-url>
        <doi>10.17487/RFC4827</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4828</doc-id>
        <title>TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>E. Kohler</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.</p><p> TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.</p><p> Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-dccp-tfrc-voip-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4828</errata-url>
        <doi>10.17487/RFC4828</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4829</doc-id>
        <title>Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering</title>
        <author>
            <name>J. de Oliveira</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Chen</name>
        </author>
        <author>
            <name>C. Scoglio</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>traffic engineering label switched path</kw>
            <kw>te lsp</kw>
            <kw>multiprotocol label switching protocol</kw>
        </keywords>
        <abstract><p>When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted.  The preempted LSPs are then rerouted by their respective \%Head-end Label Switch Router (LSR).  This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted.  Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-deoliveira-diff-te-preemption-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4829</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4830</doc-id>
        <title>Problem Statement for Network-Based Localized Mobility Management (NETLMM)</title>
        <author>
            <name>J. Kempf</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available.  This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-netlmm-nohost-ps-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <doi>10.17487/RFC4830</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4831</doc-id>
        <title>Goals for Network-Based Localized Mobility Management (NETLMM)</title>
        <author>
            <name>J. Kempf</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-netlmm-nohost-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <doi>10.17487/RFC4831</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4832</doc-id>
        <title>Security Threats to Network-Based Localized Mobility Management (NETLMM)</title>
        <author>
            <name>C. Vogt</name>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>localized mobility anchor</kw>
            <kw>mobile access gateway</kw>
            <kw>compromise</kw>
            <kw>impersonation</kw>
            <kw>man in the middle</kw>
            <kw>denial of service</kw>
            <kw>IP spoofing</kw>
        </keywords>
        <abstract><p>This document discusses security threats to network-based localized mobility management.  Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node.  Threats to the former interface impact the localized mobility management protocol itself.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-netlmm-threats-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <doi>10.17487/RFC4832</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4833</doc-id>
        <title>Timezone Options for DHCP</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>P. Eggert</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>time offset</kw>
            <kw>posix</kw>
            <kw>tz database</kw>
            <kw>tz</kw>
        </keywords>
        <abstract><p>Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names.  This memo specifies DHCP options for each of those methods.  The DHCPv4 time offset option is deprecated. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-timezone-option-05</draft>
        <updates>
            <doc-id>RFC2132</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4833</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4834</doc-id>
        <title>Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)</title>
        <author>
            <name>T. Morin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>vpn</kw>
            <kw>virtual private networks</kw>
            <kw>l3</kw>
        </keywords>
        <abstract><p>This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs).  It specifies requirements both from the end user and service provider standpoints.  It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l3vpn-ppvpn-mcast-reqts-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC4834</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4835</doc-id>
        <title>Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
        <author>
            <name>V. Manral</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ESP</kw>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>mechanism</kw>
            <kw>header</kw>
            <kw>security</kw>
            <kw>architecture</kw>
            <kw>payload</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulating</kw>
            <kw>ipv4</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA).  To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.  This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-manral-ipsec-rfc4305-bis-errata-03</draft>
        <obsoletes>
            <doc-id>RFC4305</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7321</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4835</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4836</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
        <author>
            <name>E. Beili</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>MAU-MIB</kw>
            <kw>IANA-MAU-MIB</kw>
            <kw>management information base,</kw>
        </keywords>
        <abstract><p>This document 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 document obsoletes RFC 3636.  It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module.  In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hubmib-rfc3636bis-05</draft>
        <obsoletes>
            <doc-id>RFC3636</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4836</errata-url>
        <doi>10.17487/RFC4836</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4837</doc-id>
        <title>Managed Objects of Ethernet Passive Optical Networks (EPON)</title>
        <author>
            <name>L. Khermosh</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>Ethernet Passive Optical Networks</kw>
            <kw>pon</kw>
            <kw>epon</kw>
            <kw>IEEE802.3ah</kw>
            <kw>802.3ah</kw>
            <kw>p2mp</kw>
            <kw>mpcp</kw>
            <kw>llid</kw>
            <kw>onu</kw>
            <kw>olt</kw>
            <kw>optical access</kw>
        </keywords>
        <abstract><p>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 interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hubmib-efm-epon-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC4837</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4838</doc-id>
        <title>Delay-Tolerant Networking Architecture</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>S. Burleigh</name>
        </author>
        <author>
            <name>A. Hooke</name>
        </author>
        <author>
            <name>L. Torgerson</name>
        </author>
        <author>
            <name>R. Durst</name>
        </author>
        <author>
            <name>K. Scott</name>
        </author>
        <author>
            <name>K. Fall</name>
        </author>
        <author>
            <name>H. Weiss</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>disruption tolerant</kw>
            <kw>irtf</kw>
            <kw>interplanetary internet</kw>
        </keywords>
        <abstract><p>This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration.  This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical.  We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects.  The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues.  This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-arch-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC4838</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4839</doc-id>
        <title>Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF)</title>
        <author>
            <name>G. Conboy</name>
        </author>
        <author>
            <name>J. Rivlin</name>
        </author>
        <author>
            <name>J. Ferraiolo</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-conboy-mime-opf-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4839</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4840</doc-id>
        <title>Multiple Encapsulation Methods Considered Harmful</title>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>iab</kw>
            <kw>link-layer protocol</kw>
            <kw>ip encapsulation</kw>
            <kw>internet protocol encapsulation</kw>
        </keywords>
        <abstract><p>This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-link-encaps-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4840</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4841</doc-id>
        <title>RFC 4181 Update to Recognize the IETF Trust</title>
        <author>
            <name>C. Heard</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw> standards-track specifications</kw>
            <kw>mib review</kw>
        </keywords>
        <abstract><p>This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-heard-rfc4181-update-00</draft>
        <updates>
            <doc-id>RFC4181</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0111</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4841</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4842</doc-id>
        <title>Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>P. Pate</name>
        </author>
        <author>
            <name>R. Cohen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Zelig</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
        </keywords>
        <abstract><p>This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-sonet-14</draft>
        <obsoletes>
            <doc-id>RFC5143</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4842</errata-url>
        <doi>10.17487/RFC4842</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4843</doc-id>
        <title>An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)</title>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.</p><p> This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-laganier-ipv6-khi-07</draft>
        <obsoleted-by>
            <doc-id>RFC7343</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4843</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4844</doc-id>
        <title>The RFC Series and RFC Editor</title>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>technical publisher</kw>
        </keywords>
        <abstract><p>This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-rfc-editor-04</draft>
        <obsoleted-by>
            <doc-id>RFC8729</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5741</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4844</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4845</doc-id>
        <title>Process for Publication of IAB RFCs</title>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs).  This document defines the process by which those documents are produced, reviewed, and published in the RFC Series.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-publication-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4845</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4846</doc-id>
        <title>Independent Submissions to the RFC Editor</title>
        <author>
            <name>J. Klensin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Thaler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms.  These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants.  This document discusses the Independent Submission model and some reasons why it is important.  It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-rfc-independent-00</draft>
        <updated-by>
            <doc-id>RFC5744</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4846</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4847</doc-id>
        <title>Framework and Requirements for Layer 1 Virtual Private Networks</title>
        <author>
            <name>T. Takeda</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>L1VPN</kw>
        </keywords>
        <abstract><p>This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.</p><p> The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l1vpn-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l1vpn</wg_acronym>
        <doi>10.17487/RFC4847</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4848</doc-id>
        <title>Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>service-parms</kw>
            <kw>service parameters</kw>
        </keywords>
        <abstract><p>The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols.  Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-daigle-unaptr-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4848</errata-url>
        <doi>10.17487/RFC4848</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4849</doc-id>
        <title>RADIUS Filter Rule Attribute</title>
        <author>
            <name>P. Congdon</name>
        </author>
        <author>
            <name>M. Sanchez</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>remote authentication dial in user service</kw>
            <kw>nas-filter-rule</kw>
        </keywords>
        <abstract><p>While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters.  However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly.  This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-filter-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC4849</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4850</doc-id>
        <title>Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture</title>
        <author>
            <name>D. Wysochanski</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>transport protocol</kw>
            <kw>tcp</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys.  This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability.  The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence.  The receiving node can then use this information for enhanced logging and support.  This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-iscsi-nodearch-key-03</draft>
        <obsoleted-by>
            <doc-id>RFC7143</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3720</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC4850</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4851</doc-id>
        <title>The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)</title>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>H. Zhou</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>eap</kw>
        </keywords>
        <abstract><p>This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol.  EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-cam-winget-eap-fast-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9427</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4851</errata-url>
        <doi>10.17487/RFC4851</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4852</doc-id>
        <title>IPv6 Enterprise Network Analysis - IP Layer 3 Focus</title>
        <author>
            <name>J. Bound</name>
        </author>
        <author>
            <name>Y. Pouffary</name>
        </author>
        <author>
            <name>S. Klynsma</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>D. Green</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>notational network</kw>
        </keywords>
        <abstract><p>This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3.  These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity.  The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios.  Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise.  Then, a set of transition mechanisms are recommended for each notational network.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-ent-analysis-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4852</errata-url>
        <doi>10.17487/RFC4852</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4853</doc-id>
        <title>Cryptographic Message Syntax (CMS) Multiple Signer Clarification</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>signeddata</kw>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <abstract><p>This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852.  This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-cms-mult-sign-03</draft>
        <updates>
            <doc-id>RFC3852</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4853</errata-url>
        <doi>10.17487/RFC4853</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4854</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
            <kw>Uniform Resource Name</kw>
            <kw>URN</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-saintandre-xmpp-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4854</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4855</doc-id>
        <title>Media Type Registration of RTP Payload Formats</title>
        <author>
            <name>S. Casner</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>realtime transport protocol</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names.  This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc3555bis-05</draft>
        <obsoletes>
            <doc-id>RFC3555</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8851</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4855</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4856</doc-id>
        <title>Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences</title>
        <author>
            <name>S. Casner</name>
        </author>
        <date>
            <month>February</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>realtime transport protocol</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract><p>This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences.  Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc3555bis-part2-02</draft>
        <obsoletes>
            <doc-id>RFC3555</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4856</errata-url>
        <doi>10.17487/RFC4856</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4857</doc-id>
        <title>Mobile IPv4 Regional Registration</title>
        <author>
            <name>E. Fogelstroem</name>
        </author>
        <author>
            <name>A. Jonsson</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>GFA</kw>
            <kw>gateway foreign agent</kw>
        </keywords>
        <abstract><p>Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address.  This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain.  The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain.  Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain.  This document is an optional extension to the Mobile IPv4 protocol.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mip4-reg-tunnel-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4857</errata-url>
        <doi>10.17487/RFC4857</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4858</doc-id>
        <title>Document Shepherding from Working Group Last Call to Publication</title>
        <author>
            <name>H. Levkowetz</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>document shepherding</kw>
            <kw>ietf documents</kw>
        </keywords>
        <abstract><p>This document describes methodologies that have been designed to improve and facilitate IETF document flow processing.  It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication.  Before this, the Area Director responsible for the working group has traditionally filled the shepherding role.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-proto-wgchair-doc-shepherding-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4858</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4859</doc-id>
        <title>Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-iana-rsvp-session-flags-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4859</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4860</doc-id>
        <title>Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>P. Bose</name>
        </author>
        <author>
            <name>C. Christou</name>
        </author>
        <author>
            <name>M. Davenport</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>session object</kw>
            <kw>session of interest</kw>
            <kw>phb</kw>
            <kw>per hop behavior</kw>
        </keywords>
        <abstract><p>RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination.  RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud.  There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs).  However, this is not supported by the aggregate reservations defined in RFC 3175.  In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation.  Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address.  The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations.  This document also defines the procedures for such aggregation.  The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-ipsec-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4860</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4861</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>
        <author>
            <name>H. Soliman</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>97</page-count>
        <keywords>
            <kw>IPV6-ND</kw>
            <kw>internet protocol</kw>
            <kw>link-layer</kw>
            <kw>link-layer address</kw>
        </keywords>
        <abstract><p>This document specifies the Neighbor Discovery protocol for IP Version 6.  IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-2461bis-11</draft>
        <obsoletes>
            <doc-id>RFC2461</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5942</doc-id>
            <doc-id>RFC6980</doc-id>
            <doc-id>RFC7048</doc-id>
            <doc-id>RFC7527</doc-id>
            <doc-id>RFC7559</doc-id>
            <doc-id>RFC8028</doc-id>
            <doc-id>RFC8319</doc-id>
            <doc-id>RFC8425</doc-id>
            <doc-id>RFC9131</doc-id>
            <doc-id>RFC9685</doc-id>
            <doc-id>RFC9762</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4861</errata-url>
        <doi>10.17487/RFC4861</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4862</doc-id>
        <title>IPv6 Stateless Address Autoconfiguration</title>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>T. Jinmei</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>IPV6-AUTO</kw>
            <kw>host</kw>
            <kw>link-local</kw>
            <kw>internet protocol version 6</kw>
            <kw>link-local address</kw>
            <kw>duplicate address detection</kw>
        </keywords>
        <abstract><p>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6.  The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-rfc2462bis-08</draft>
        <obsoletes>
            <doc-id>RFC2462</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7527</doc-id>
            <doc-id>RFC9762</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4862</errata-url>
        <doi>10.17487/RFC4862</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4863</doc-id>
        <title>Wildcard Pseudowire Type</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>pw type</kw>
            <kw>pw</kw>
        </keywords>
        <abstract><p>Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions.  For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint.  In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP.  In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP.  This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-wildcard-pw-type-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC4863</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4864</doc-id>
        <title>Local Network Protection for IPv6</title>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>T. Hain</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>E. Klein</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>address</kw>
            <kw>protection</kw>
            <kw>nat</kw>
        </keywords>
        <abstract><p>Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6.  In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site.  IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-nap-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4864</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4865</doc-id>
        <title>SMTP Submission Service Extension for Future Message Release</title>
        <author>
            <name>G. White</name>
        </author>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>simple mail transfer protocol</kw>
            <kw>future-release-integer</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery.  This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future.  This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-vaudreuil-futuredelivery-04</draft>
        <updates>
            <doc-id>RFC3463</doc-id>
            <doc-id>RFC3464</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4865</errata-url>
        <doi>10.17487/RFC4865</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4866</doc-id>
        <title>Enhanced Route Optimization for Mobile IPv6</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>C. Vogt</name>
        </author>
        <author>
            <name>W. Haddad</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>mobility</kw>
            <kw>cryptographically generated addresses</kw>
            <kw>cga</kw>
            <kw>credit-based authorization</kw>
            <kw>cba</kw>
        </keywords>
        <abstract><p>This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-cga-cba-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4866</errata-url>
        <doi>10.17487/RFC4866</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4867</doc-id>
        <title>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>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>interoperate</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>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 media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format.  This document obsoletes RFC 3267. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-amr-bis-06</draft>
        <obsoletes>
            <doc-id>RFC3267</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4867</errata-url>
        <doi>10.17487/RFC4867</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4868</doc-id>
        <title>Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec</title>
        <author>
            <name>S. Kelly</name>
        </author>
        <author>
            <name>S. Frankel</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>hashed authentication mode</kw>
            <kw>data authentication</kw>
            <kw>integrity verification</kw>
        </keywords>
        <abstract><p>This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec.  These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2.  Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256.  The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kelly-ipsec-ciph-sha2-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4868</errata-url>
        <doi>10.17487/RFC4868</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4869</doc-id>
        <title>Suite B Cryptographic Suites for IPsec</title>
        <author>
            <name>L. Law</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ui suites</kw>
            <kw>user interface suites</kw>
            <kw>elliptic curve</kw>
            <kw>ike</kw>
        </keywords>
        <abstract><p>This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308.  The four new suites provide compatibility with the United States National Security Agency's Suite B specifications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-solinas-ui-suites-01</draft>
        <obsoleted-by>
            <doc-id>RFC6379</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4869</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4870</doc-id>
        <title>Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)</title>
        <author>
            <name>M. Delany</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.</p><p> This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.</p><p> Proof and protection of email identity may assist in the global control of "spam" and "phishing". This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-delany-domainkeys-base-06</draft>
        <obsoleted-by>
            <doc-id>RFC4871</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4870</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4871</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Signatures</title>
        <author>
            <name>E. Allman</name>
        </author>
        <author>
            <name>J. Callas</name>
        </author>
        <author>
            <name>M. Delany</name>
        </author>
        <author>
            <name>M. Libbey</name>
        </author>
        <author>
            <name>J. Fenton</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>internet mail</kw>
            <kw>authentication</kw>
            <kw>spam</kw>
            <kw>phishing</kw>
            <kw>spoofing</kw>
            <kw>digital signature</kw>
        </keywords>
        <abstract><p>DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs).  The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today.  Protection of email identity may assist in the global control of "spam" and "phishing". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dkim-base-10</draft>
        <obsoletes>
            <doc-id>RFC4870</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6376</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5672</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4871</errata-url>
        <doi>10.17487/RFC4871</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4872</doc-id>
        <title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery</title>
        <author>
            <name>J.P. Lang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>resource reservation protocol</kw>
            <kw>traffic engineering</kw>
        </keywords>
        <abstract><p>This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration.  A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4873</doc-id>
            <doc-id>RFC6780</doc-id>
            <doc-id>RFC9270</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4872</errata-url>
        <doi>10.17487/RFC4872</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4873</doc-id>
        <title>GMPLS Segment Recovery</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>generalized multipoint label switching</kw>
            <kw>rsvp-te</kw>
            <kw>resource reservation protocol</kw>
            <kw>traffic engineering</kw>
            <kw>NOTIFY_REQUEST</kw>
        </keywords>
        <abstract><p>This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration.  These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).  Implications and interactions with fast reroute are also addressed.  This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-segment-recovery-03</draft>
        <updates>
            <doc-id>RFC3473</doc-id>
            <doc-id>RFC4872</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9270</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4873</errata-url>
        <doi>10.17487/RFC4873</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4874</doc-id>
        <title>Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)</title>
        <author>
            <name>CY. Lee</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>S. De Cnodder</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>srlg</kw>
            <kw>shared risk link groups</kw>
        </keywords>
        <abstract><p>This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).</p><p> The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.</p><p> In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rsvp-te-exclude-route-06</draft>
        <updates>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6001</doc-id>
            <doc-id>RFC8390</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4874</errata-url>
        <doi>10.17487/RFC4874</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4875</doc-id>
        <title>Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
        <author>
            <name>R. Aggarwal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Yasukawa</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>p2mp</kw>
            <kw>point-to-multipoint</kw>
            <kw>traffic engineering</kw>
        </keywords>
        <abstract><p>This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.</p><p> There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-rsvp-te-p2mp-07</draft>
        <updated-by>
            <doc-id>RFC6510</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4875</errata-url>
        <doi>10.17487/RFC4875</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4876</doc-id>
        <title>A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents</title>
        <author>
            <name>B. Neal-Joslin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Howard</name>
        </author>
        <author>
            <name>M. Ansari</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>ldap</kw>
            <kw>schema</kw>
            <kw>profile</kw>
            <kw>configuration</kw>
            <kw>nameservice</kw>
            <kw>nss</kw>
            <kw>pam_ldap</kw>
            <kw>nss_ldap</kw>
            <kw>rfc2307</kw>
            <kw>rfc 2307</kw>
        </keywords>
        <abstract><p>This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents.  A set of attribute types and an object class are proposed.  In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support.  In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment.  This document is intended to be a skeleton for future documents that describe configuration of specific DUA services.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-joslin-config-schema-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4876</errata-url>
        <doi>10.17487/RFC4876</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4877</doc-id>
        <title>Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture</title>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Bootstrapping</kw>
            <kw>MIP6</kw>
            <kw>Selector Granularity</kw>
            <kw>Mobility Header</kw>
            <kw>EAP Authentication</kw>
        </keywords>
        <abstract><p>This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-ikev2-ipsec-08</draft>
        <updates>
            <doc-id>RFC3776</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4877</errata-url>
        <doi>10.17487/RFC4877</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4878</doc-id>
        <title>Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces</title>
        <author>
            <name>M. Squire</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>efm</kw>
            <kw>ethernet in the first mile</kw>
            <kw>snmp</kw>
            <kw>DOT3-OAM-MIB</kw>
        </keywords>
        <abstract><p>This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards.  The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces.  This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hubmib-efm-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC4878</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4879</doc-id>
        <title>Clarification of the Third Party Disclosure Procedure in RFC 3979</title>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>ipr</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>This document clarifies and updates a single sentence in RFC 3979.  Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-narten-ipr-3979-3rd-party-fix-00</draft>
        <obsoleted-by>
            <doc-id>RFC8179</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3979</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <doi>10.17487/RFC4879</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4880</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>D. Shaw</name>
        </author>
        <author>
            <name>R. Thayer</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>public-key cryptography</kw>
            <kw>symmetric cryptography</kw>
        </keywords>
        <abstract><p>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</p><p> OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-openpgp-rfc2440bis-22</draft>
        <obsoletes>
            <doc-id>RFC1991</doc-id>
            <doc-id>RFC2440</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9580</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5581</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>openpgp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4880</errata-url>
        <doi>10.17487/RFC4880</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4881</doc-id>
        <title>Low-Latency Handoffs in Mobile IPv4</title>
        <author>
            <name>K. El Malki</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>mip4</kw>
        </keywords>
        <abstract><p>Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents.  In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services.  The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs.  In addition, a combination of these two methods is described.  The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mobileip-lowlatency-handoffs-v4-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC4881</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4882</doc-id>
        <title>IP Address Location Privacy and Mobile IPv6: Problem Statement</title>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>home address</kw>
            <kw>care-of address</kw>
        </keywords>
        <abstract><p>In this document, we discuss location privacy as applicable to Mobile IPv6.  We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-location-privacy-ps-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC4882</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4883</doc-id>
        <title>Benchmarking Terminology for Resource Reservation Capable Routers</title>
        <author>
            <name>G. Feher</name>
        </author>
        <author>
            <name>K. Nemeth</name>
        </author>
        <author>
            <name>A. Korn</name>
        </author>
        <author>
            <name>I. Cselenyi</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>intserv</kw>
            <kw>integrated services</kw>
            <kw>benchmarking methodologies</kw>
        </keywords>
        <abstract><p>The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers.  These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-benchres-term-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC4883</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4884</doc-id>
        <title>Extended ICMP to Support Multi-Part Messages</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>D. Gan</name>
        </author>
        <author>
            <name>D. Tappan</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>April</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>internet control message protocol</kw>
            <kw>length attribute</kw>
        </keywords>
        <abstract><p>This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.</p><p> Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.</p><p> This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.</p><p> The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.</p><p> This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-bonica-internet-icmp-16</draft>
        <updates>
            <doc-id>RFC0792</doc-id>
            <doc-id>RFC4443</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8335</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4884</errata-url>
        <doi>10.17487/RFC4884</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4885</doc-id>
        <title>Network Mobility Support Terminology</title>
        <author>
            <name>T. Ernst</name>
        </author>
        <author>
            <name>H-Y. Lach</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>nemo</kw>
        </keywords>
        <abstract><p>This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nemo-terminology-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4885</errata-url>
        <doi>10.17487/RFC4885</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4886</doc-id>
        <title>Network Mobility Support Goals and Requirements</title>
        <author>
            <name>T. Ernst</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>nemo</kw>
        </keywords>
        <abstract><p>Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology.  Such a type of network is referred to as a mobile network.  With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment.  This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nemo-requirements-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4886</errata-url>
        <doi>10.17487/RFC4886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4887</doc-id>
        <title>Network Mobility Home Network Models</title>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>nemo</kw>
            <kw>mobile routers</kw>
        </keywords>
        <abstract><p>This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support.  The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nemo-home-network-models-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <doi>10.17487/RFC4887</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4888</doc-id>
        <title>Network Mobility Route Optimization Problem Statement</title>
        <author>
            <name>C. Ng</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>M. Watari</name>
        </author>
        <author>
            <name>F. Zhao</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>nemo</kw>
        </keywords>
        <abstract><p>With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away.  This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes.  Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions.  This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nemo-ro-problem-statement-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4888</errata-url>
        <doi>10.17487/RFC4888</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4889</doc-id>
        <title>Network Mobility Route Optimization Solution Space Analysis</title>
        <author>
            <name>C. Ng</name>
        </author>
        <author>
            <name>F. Zhao</name>
        </author>
        <author>
            <name>M. Watari</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>nemo</kw>
            <kw>mrha</kw>
            <kw>mobile router and home agent</kw>
            <kw>ro</kw>
        </keywords>
        <abstract><p>With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away.  This results in increased length of packet route and increased packet delay in most cases.  To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO.  This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nemo-ro-space-analysis-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4889</errata-url>
        <doi>10.17487/RFC4889</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4890</doc-id>
        <title>Recommendations for Filtering ICMPv6 Messages in Firewalls</title>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>J. Mohacsi</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>Internet Control Message Protocol version 6</kw>
            <kw>ipv6</kw>
            <kw>security</kw>
            <kw>filter</kw>
            <kw>firewall</kw>
            <kw>icmpv6</kw>
        </keywords>
        <abstract><p>In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.</p><p> This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-icmpv6-filtering-recs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4890</errata-url>
        <doi>10.17487/RFC4890</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4891</doc-id>
        <title>Using IPsec to Secure IPv6-in-IPv4 Tunnels</title>
        <author>
            <name>R. Graveman</name>
        </author>
        <author>
            <name>M. Parthasarathy</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>internet protocol security</kw>
            <kw>ip security</kw>
        </keywords>
        <abstract><p>This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode.  No additional protocol extensions are described beyond those available with the IPsec framework.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-ipsec-tunnels-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4891</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4892</doc-id>
        <title>Requirements for a Mechanism Identifying a Name Server Instance</title>
        <author>
            <name>S. Woolf</name>
        </author>
        <author>
            <name>D. Conrad</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>domain name service</kw>
            <kw>dns name server</kw>
        </keywords>
        <abstract><p>With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query.  A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators.  Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed.  This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsop-serverid-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC4892</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4893</doc-id>
        <title>BGP Support for Four-octet AS Number Space</title>
        <author>
            <name>Q. Vohra</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>autonomous system</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP.  This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-as4bytes-13</draft>
        <obsoleted-by>
            <doc-id>RFC6793</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC4893</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4894</doc-id>
        <title>Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>md5</kw>
            <kw>pkix</kw>
            <kw>certificates</kw>
        </keywords>
        <abstract><p>This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hoffman-ike-ipsec-hash-use-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4894</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4895</doc-id>
        <title>Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>P. Lei</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>chunk type</kw>
            <kw>shared keys</kw>
            <kw>RANDOM</kw>
            <kw>CHUNKS</kw>
            <kw>HMAC-ALGO</kw>
        </keywords>
        <abstract><p>This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP).  This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver.  The new parameters are used to establish the shared keys. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-auth-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4895</errata-url>
        <doi>10.17487/RFC4895</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4896</doc-id>
        <title>Signaling Compression (SigComp) Corrections and Clarifications</title>
        <author>
            <name>A. Surtees</name>
        </author>
        <author>
            <name>M. West</name>
        </author>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>udvm</kw>
            <kw>universal decompressor virtual machine</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract><p>This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems.  SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP).  This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-sigcomp-impl-guide-10</draft>
        <updates>
            <doc-id>RFC3320</doc-id>
            <doc-id>RFC3321</doc-id>
            <doc-id>RFC3485</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4896</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4897</doc-id>
        <title>Handling Normative References to Standards-Track Documents</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher.  This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level.  The IETF agreed on a way to bypass this rule with RFC 3967.  This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on".  The procedure in RFC 3967 still applies for downward references to other classes of documents.  In both cases, annotations should be added to such References.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-klensin-norm-ref-04</draft>
        <updates>
            <doc-id>RFC3967</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0097</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4897</errata-url>
        <doi>10.17487/RFC4897</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4898</doc-id>
        <title>TCP Extended Statistics MIB</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>J. Heffner</name>
        </author>
        <author>
            <name>R. Raghunarayan</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>management information base</kw>
            <kw>TCP-ESTATS-MIB</kw>
        </keywords>
        <abstract><p>This document describes extended performance statistics for TCP.  They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application.  If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself.  If the bottleneck is in the network, TCP can provide specific information about its nature. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-tcp-mib-extension-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4898</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4899</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4900</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4901</doc-id>
        <title>Protocol Extensions for Header Compression over MPLS</title>
        <author>
            <name>J. Ash</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Hand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>hc</kw>
        </keywords>
        <abstract><p>This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path.  HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router).  Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers.  This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP.  This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols.  In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-hc-over-mpls-protocol-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC4901</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4902</doc-id>
        <title>Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP</title>
        <author>
            <name>M. Stecher</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.</p><p> The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-opes-smtp-security-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>opes</wg_acronym>
        <doi>10.17487/RFC4902</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4903</doc-id>
        <title>Multi-Link Subnet Issues</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>There have been several proposals around the notion that a subnet may span multiple links connected by routers.  This memo documents the issues and potential problems that have been raised with such an approach.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-multilink-subnet-issues-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4903</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4904</doc-id>
        <title>Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SIP TEL</kw>
            <kw>Trunk group</kw>
            <kw>trunkgroup</kw>
            <kw>PSTN</kw>
        </keywords>
        <abstract><p>This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs).  An extension to the tel URI is defined for this purpose. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-iptel-trunk-group-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC4904</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4905</doc-id>
        <title>Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. El-Aawar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>pdu</kw>
            <kw>protocol data unit</kw>
            <kw>draft-martini</kw>
        </keywords>
        <abstract><p>This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network.  This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.  This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-martini-l2circuit-encap-mpls-12</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4905</errata-url>
        <doi>10.17487/RFC4905</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4906</doc-id>
        <title>Transport of Layer 2 Frames Over MPLS</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. El-Aawar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>pdu</kw>
            <kw>protocol data unit</kw>
            <kw>sonet</kw>
            <kw>synchronized optical network</kw>
        </keywords>
        <abstract><p>This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network.  This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.  This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-martini-l2circuit-trans-mpls-19</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4906</errata-url>
        <doi>10.17487/RFC4906</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4907</doc-id>
        <title>Architectural Implications of Link Indications</title>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <abstract><p>A link indication represents information provided by the link layer to higher layers regarding the state of the link.  This document describes the role of link indications within the Internet architecture.  While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance.  This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-link-indications-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4907</errata-url>
        <doi>10.17487/RFC4907</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4908</doc-id>
        <title>Multi-homing for small scale fixed network Using Mobile IP and NEMO</title>
        <author>
            <name>K. Nagami</name>
        </author>
        <author>
            <name>S. Uda</name>
        </author>
        <author>
            <name>N. Ogashiwa</name>
        </author>
        <author>
            <name>H. Esaki</name>
        </author>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>H. Ohnishi</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>care-of addresses</kw>
        </keywords>
        <abstract><p>Multihoming technology improves the availability of host and network connectivity.  Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed.  This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963).  The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used.  In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-nagami-mip6-nemo-multihome-fixed-network-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4908</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4909</doc-id>
        <title>Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport</title>
        <author>
            <name>L. Dondeti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Castleford</name>
        </author>
        <author>
            <name>F. Hartung</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>short-term key message</kw>
            <kw>long-term key message</kw>
            <kw>oma</kw>
            <kw>bac</kw>
            <kw>browser and content</kw>
            <kw>broadcast</kw>
        </keywords>
        <abstract><p>This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dondeti-msec-mikey-genext-oma-04</draft>
        <obsoleted-by>
            <doc-id>RFC5410</doc-id>
            <doc-id>RFC6309</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4909</errata-url>
        <doi>10.17487/RFC4909</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4910</doc-id>
        <title>Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)</title>
        <author>
            <name>S. Legg</name>
        </author>
        <author>
            <name>D. Prager</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>canonical rxer</kw>
            <kw>crxer</kw>
        </keywords>
        <abstract><p>This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type.  Rules for producing a canonical RXER encoding are also defined.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-legg-xed-rxer-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4910</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4911</doc-id>
        <title>Encoding Instructions for the Robust XML Encoding Rules (RXER)</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>asn.1</kw>
            <kw>abstract syntax notation one</kw>
            <kw>robust xml encoding rules</kw>
            <kw>rxer</kw>
            <kw>canonical robust xml encoding rules</kw>
            <kw>crxer</kw>
            <kw>asn.x</kw>
        </keywords>
        <abstract><p>This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element.  Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification.  Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-legg-xed-rxer-ei-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4911</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4912</doc-id>
        <title>Abstract Syntax Notation X (ASN.X)</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>165</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>asn.1</kw>
            <kw>abstract syntax notation one</kw>
            <kw>robust xml encoding rules</kw>
            <kw>rxer</kw>
        </keywords>
        <abstract><p>Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications.  ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications.  ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-legg-xed-asd-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4912</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4913</doc-id>
        <title>Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications.  This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-legg-xed-asd-gserei-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4913</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4914</doc-id>
        <title>Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications.  This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-legg-xed-asd-xerei-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4914</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4915</doc-id>
        <title>Multi-Topology (MT) Routing in OSPF</title>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>S. Mirtorabi</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.</p><p> An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-mt-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC4915</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4916</doc-id>
        <title>Connected Identity in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Elwell</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>user agent</kw>
            <kw>ua</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract><p>This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service.  Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field.  The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway.  This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-connected-identity-05</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC4916</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4917</doc-id>
        <title>Mobile IPv4 Message String Extension</title>
        <author>
            <name>V. Sastry</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>A. Patel</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>home agent</kw>
            <kw>foreign agent</kw>
            <kw>registration reply</kw>
        </keywords>
        <abstract><p>This document specifies a new extension for use in Mobile IPv4.  This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages.  This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-message-string-ext-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC4917</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4918</doc-id>
        <title>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</title>
        <author>
            <name>L. Dusseault</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>127</page-count>
        <keywords>
            <kw>WEBDAV</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>web</kw>
            <kw>content</kw>
        </keywords>
        <abstract><p>Web Distributed Authoring and Versioning (WebDAV) consists of 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, URL namespace manipulation, and resource locking (collision avoidance).</p><p> RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-webdav-rfc2518bis-18</draft>
        <obsoletes>
            <doc-id>RFC2518</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5689</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>webdav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4918</errata-url>
        <doi>10.17487/RFC4918</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4919</doc-id>
        <title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals</title>
        <author>
            <name>N. Kushalnagar</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>C. Schumacher</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ieee 802.15.4</kw>
        </keywords>
        <abstract><p>This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks.  The set of goals enumerated in this document form an initial set only.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-6lowpan-problem-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lowpan</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4919</errata-url>
        <doi>10.17487/RFC4919</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4920</doc-id>
        <title>Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Satyanarayana</name>
        </author>
        <author>
            <name>A. Iwata</name>
        </author>
        <author>
            <name>N. Fujita</name>
        </author>
        <author>
            <name>G. Ash</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>generalized multiprotocol label switching</kw>
            <kw>traffic engineered</kw>
            <kw>te</kw>
            <kw>lsp</kw>
            <kw>label switched path</kw>
        </keywords>
        <abstract><p>In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.</p><p> This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-crankback-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4920</errata-url>
        <doi>10.17487/RFC4920</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4921</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4922</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4923</doc-id>
        <title>Quality of Service (QoS) Signaling in a Nested Virtual Private Network</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>P. Bose</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>vpn</kw>
            <kw>nested vpn</kw>
            <kw>integrated services</kw>
        </keywords>
        <abstract><p>Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence.  This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-vpn-signaled-preemption-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC4923</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4924</doc-id>
        <title>Reflections on Internet Transparency</title>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues.  Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication.  This document provides some specific illustrations of those potential impacts.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-net-transparent-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC4924</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4925</doc-id>
        <title>Softwire Problem Statement</title>
        <author>
            <name>X. Li</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Dawkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Ward</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Durand</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks.  The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems.  This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group.  Some requirements (and non-requirements) are also identified to better describe the specific problem scope.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-softwire-problem-statement-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC4925</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4926</doc-id>
        <title>A URN Namespace for GEANT</title>
        <author>
            <name>T. Kalin</name>
        </author>
        <author>
            <name>M. Molina</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>uniform resource name</kw>
            <kw>dante</kw>
        </keywords>
        <abstract><p>This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and Research Networks, its projects, activities, working groups, and other designated subordinates.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kalin-geant-urn-namespace-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4926</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4927</doc-id>
        <title>Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>J.-L. Le Roux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>gmpls</kw>
            <kw>te-lsp</kw>
            <kw>traffic engineered label switched path</kw>
            <kw>pce</kw>
            <kw>path computation element</kw>
        </keywords>
        <abstract><p>For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas.  An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas.  In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path.  One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths.  The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses.  This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation.  It complements the generic requirements for a PCE Communication Protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-pcecp-interarea-reqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC4927</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4928</doc-id>
        <title>Avoiding Equal Cost Multipath Treatment in MPLS Networks</title>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ECMP</kw>
        </keywords>
        <abstract><p>This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks.  This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths.  These recommendations rely on inspection of the IP version number field in packets.  Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-mpls-ecmp-bcp-03</draft>
        <updated-by>
            <doc-id>RFC7274</doc-id>
            <doc-id>RFC9790</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0128</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4928</errata-url>
        <doi>10.17487/RFC4928</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4929</doc-id>
        <title>Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures</title>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols.  This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work.  This document does not modify IETF processes.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-andersson-rtg-gmpls-change-08</draft>
        <is-also>
            <doc-id>BCP0129</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4929</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4930</doc-id>
        <title>Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>shared framework mapping</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 3730. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-epp-rfc3730bis-04</draft>
        <obsoletes>
            <doc-id>RFC3730</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5730</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4930</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4931</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Domain Name Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 3731. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-epp-rfc3731bis-05</draft>
        <obsoletes>
            <doc-id>RFC3731</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5731</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4931</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4932</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Host Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 3732. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-epp-rfc3732bis-04</draft>
        <obsoletes>
            <doc-id>RFC3732</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5732</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4932</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4933</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Contact Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 3733. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-epp-rfc3733bis-06</draft>
        <obsoletes>
            <doc-id>RFC3733</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5733</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4933</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4934</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Transport Over TCP</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>mapping</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>tls</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 3734. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-epp-rfc3734bis-05</draft>
        <obsoletes>
            <doc-id>RFC3734</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5734</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4934</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4935</doc-id>
        <title>Fibre Channel Fabric Configuration Server MIB</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>H.K. Vivek</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-FABRIC-CONFIG-SERVER-MIB</kw>
        </keywords>
        <abstract><p>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 Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-fcs-mib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4935</errata-url>
        <doi>10.17487/RFC4935</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4936</doc-id>
        <title>Fibre Channel Zone Server MIB</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>H.K. Vivek</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-FABRIC-LOCK-MIB</kw>
            <kw>T11-FC-ZONE-SERVER-MIB</kw>
        </keywords>
        <abstract><p>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 a Fibre Channel Zone Server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-zs-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC4936</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4937</doc-id>
        <title>IANA Considerations for PPP over Ethernet (PPPoE)</title>
        <author>
            <name>P. Arberg</name>
        </author>
        <author>
            <name>V. Mammoliti</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-arberg-pppoe-iana-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4937</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4938</doc-id>
        <title>PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics</title>
        <author>
            <name>B. Berry</name>
        </author>
        <author>
            <name>H. Holgate</name>
        </author>
        <date>
            <month>June</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report.  This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-bberry-pppoe-credit-06</draft>
        <obsoleted-by>
            <doc-id>RFC5578</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4938</errata-url>
        <doi>10.17487/RFC4938</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4939</doc-id>
        <title>Definitions of Managed Objects for iSNS (Internet Storage Name Service)</title>
        <author>
            <name>K. Gibbons</name>
        </author>
        <author>
            <name>G. Ramkumar</name>
        </author>
        <author>
            <name>S. Kipp</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>iscsi</kw>
            <kw>internet small computer system interface</kw>
            <kw>ifcp</kw>
            <kw>internet fibre channel protocol</kw>
            <kw>ISNS-MIB</kw>
        </keywords>
        <abstract><p>The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage.  This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-isns-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4939</errata-url>
        <doi>10.17487/RFC4939</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4940</doc-id>
        <title>IANA Considerations for OSPF</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>B. Fenner</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ospf-iana-03</draft>
        <is-also>
            <doc-id>BCP0130</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4940</errata-url>
        <doi>10.17487/RFC4940</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4941</doc-id>
        <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>R. Draves</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>privacy</kw>
            <kw>anonymity</kw>
            <kw>unlinkability</kw>
            <kw>crypto-based address changing</kw>
        </keywords>
        <abstract><p>Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers.  Addresses are formed by combining network prefixes with an interface identifier.  On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it.  On other interface types, the interface identifier is generated through other means, for example, via random number generation.  This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier.  Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier.  Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-privacy-addrs-v2-05</draft>
        <obsoletes>
            <doc-id>RFC3041</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8981</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4941</errata-url>
        <doi>10.17487/RFC4941</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4942</doc-id>
        <title>IPv6 Transition/Co-existence Security Considerations</title>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>dual-protocol network</kw>
            <kw>ipv4</kw>
        </keywords>
        <abstract><p>The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories:</p><p> o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.</p><p> This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-security-overview-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4942</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4943</doc-id>
        <title>IPv6 Neighbor Discovery On-Link Assumption Considered Harmful</title>
        <author>
            <name>S. Roy</name>
        </author>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>J. Paugh</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract><p>This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6).  According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link.  This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router).  This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-onlinkassumption-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC4943</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4944</doc-id>
        <title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>N. Kushalnagar</name>
        </author>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>D. Culler</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>link-local address</kw>
            <kw>stateless autoconfiguration</kw>
        </keywords>
        <abstract><p>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 IEEE 802.15.4 networks.  Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6lowpan-format-13</draft>
        <updated-by>
            <doc-id>RFC6282</doc-id>
            <doc-id>RFC6775</doc-id>
            <doc-id>RFC8025</doc-id>
            <doc-id>RFC8066</doc-id>
            <doc-id>RFC8931</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lowpan</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4944</errata-url>
        <doi>10.17487/RFC4944</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4945</doc-id>
        <title>The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX</title>
        <author>
            <name>B. Korver</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>internet key exchange</kw>
            <kw>public key infrastructure for x.509</kw>
            <kw>ipsec</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application.  This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec.  The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly.  This document addresses those issues.  The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pki4ipsec-ikecert-profile-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pki4ipsec</wg_acronym>
        <doi>10.17487/RFC4945</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4946</doc-id>
        <title>Atom License Extension</title>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>atom syndication format</kw>
            <kw>atom feeds</kw>
            <kw>atom entries</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-snell-atompub-feed-license-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4946</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4947</doc-id>
        <title>Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>M. Montpetit</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>encapsulate</kw>
            <kw>motion picture experts group</kw>
            <kw>unidirectional link protocol</kw>
            <kw>UniDirectional Link Routing</kw>
            <kw>address resolution protocol</kw>
        </keywords>
        <abstract><p>This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.</p><p> In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipdvb-ar-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipdvb</wg_acronym>
        <doi>10.17487/RFC4947</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4948</doc-id>
        <title>Report from the IAB workshop on Unwanted Traffic March 9-10, 2006</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>spam</kw>
            <kw>botnet</kw>
        </keywords>
        <abstract><p>This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic.  The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA.  The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions.  It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-iwout-report-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4948</errata-url>
        <doi>10.17487/RFC4948</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4949</doc-id>
        <title>Internet Security Glossary, Version 2</title>
        <author>
            <name>R. Shirey</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>365</page-count>
        <keywords>
            <kw>abbreviation</kw>
            <kw>clarity</kw>
            <kw>definition</kw>
            <kw>dictionary</kw>
            <kw>language</kw>
            <kw>punctuation</kw>
            <kw>synonym</kw>
            <kw>terminology</kw>
            <kw>writing</kw>
        </keywords>
        <abstract><p>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security.  The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026).  The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shirey-secgloss-v2-08</draft>
        <obsoletes>
            <doc-id>RFC2828</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0036</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4949</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4950</doc-id>
        <title>ICMP Extensions for Multiprotocol Label Switching</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>D. Gan</name>
        </author>
        <author>
            <name>D. Tappan</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Internet Control Message Protocol</kw>
        </keywords>
        <abstract><p>This memo defines an extension object that can be appended to selected multi-part ICMP messages.  This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-icmp-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC4950</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4951</doc-id>
        <title>Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"</title>
        <author>
            <name>V. Jain</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>control connection</kw>
            <kw>layer 2  connectivity</kw>
        </keywords>
        <abstract><p>Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints.  Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection.  When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection.  Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available.  Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-failover-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC4951</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4952</doc-id>
        <title>Overview and Framework for Internationalized Email</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>Y. Ko</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>smtp</kw>
        </keywords>
        <abstract><p>Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses.  This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses.  These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data.  The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-framework-05</draft>
        <obsoleted-by>
            <doc-id>RFC6530</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5336</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4952</errata-url>
        <doi>10.17487/RFC4952</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4953</doc-id>
        <title>Defending TCP Against Spoofing Attacks</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>rst</kw>
            <kw>transport control protocol</kw>
        </keywords>
        <abstract><p>Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing).  TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers.  For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number.  The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks.  This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment.  This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-antispoof-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC4953</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4954</doc-id>
        <title>SMTP Service Extension for Authentication</title>
        <author>
            <name>R. Siemborski</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>simple mail transport protocol</kw>
            <kw>security layer</kw>
            <kw>sasl</kw>
        </keywords>
        <abstract><p>This document defines a Simple Mail Transport Protocol (SMTP) extension 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 during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.</p><p> This document obsoletes RFC 2554. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-siemborski-rfc2554bis-09</draft>
        <obsoletes>
            <doc-id>RFC2554</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3463</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5248</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4954</errata-url>
        <doi>10.17487/RFC4954</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4955</doc-id>
        <title>DNS Security (DNSSEC) Experiments</title>
        <author>
            <name>D. Blacka</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>domain namespace</kw>
        </keywords>
        <abstract><p>This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-experiments-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC4955</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4956</doc-id>
        <title>DNS Security (DNSSEC) Opt-In</title>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>M. Kosters</name>
        </author>
        <author>
            <name>D. Blacka</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>domain namespace</kw>
        </keywords>
        <abstract><p>In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured.  Maintaining this cryptography is not always practical or necessary.  This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-opt-in-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4956</errata-url>
        <doi>10.17487/RFC4956</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4957</doc-id>
        <title>Link-Layer Event Notifications for Detecting Network Attachments</title>
        <author>
            <name>S. Krishnan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Montavont</name>
        </author>
        <author>
            <name>E. Njedjou</name>
        </author>
        <author>
            <name>S. Veerepalli</name>
        </author>
        <author>
            <name>A. Yegin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>Certain network access technologies are capable of providing various types of link-layer status information to IP.  Link-layer event notifications can help IP expeditiously detect configuration changes.  This document provides a non-exhaustive catalogue of information available from well-known access technologies.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dna-link-information-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dna</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4957</errata-url>
        <doi>10.17487/RFC4957</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4958</doc-id>
        <title>A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain</title>
        <author>
            <name>K. Carlberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>priority</kw>
            <kw>prioritization</kw>
            <kw>preferential service</kw>
        </keywords>
        <abstract><p>This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain.  Comments about their potential usage as well as their current deployment are provided to the reader.  Specific solutions are not presented.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ieprep-domain-frame-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ieprep</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4958</errata-url>
        <doi>10.17487/RFC4958</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4959</doc-id>
        <title>IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response</title>
        <author>
            <name>R. Siemborski</name>
        </author>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>imap authenticate</kw>
            <kw>internet message access protocol</kw>
        </keywords>
        <abstract><p>To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.</p><p> This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-siemborski-imap-sasl-initial-response-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4959</errata-url>
        <doi>10.17487/RFC4959</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4960</doc-id>
        <title>Stream Control Transmission Protocol</title>
        <author>
            <name>R. Stewart</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>152</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>transport</kw>
            <kw>packet</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</p><p> SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:</p><p> -- acknowledged error-free non-duplicated transfer of user data,</p><p> -- data fragmentation to conform to discovered path MTU size,</p><p> -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</p><p> -- optional bundling of multiple user messages into a single SCTP packet, and</p><p> -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</p><p> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-2960bis-05</draft>
        <obsoletes>
            <doc-id>RFC2960</doc-id>
            <doc-id>RFC3309</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9260</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6096</doc-id>
            <doc-id>RFC6335</doc-id>
            <doc-id>RFC7053</doc-id>
            <doc-id>RFC8899</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4960</errata-url>
        <doi>10.17487/RFC4960</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4961</doc-id>
        <title>Symmetric RTP / RTP Control Protocol (RTCP)</title>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>symmetric rtcp</kw>
        </keywords>
        <abstract><p>This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP".  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-wing-behave-symmetric-rtprtcp-03</draft>
        <is-also>
            <doc-id>BCP0131</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4961</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4962</doc-id>
        <title>Guidance for Authentication, Authorization, and Accounting (AAA) Key Management</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols.  The guidance is also useful to designers of systems and solutions that include AAA key management protocols.  Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols.  The guidelines in this document apply to documents requesting publication as IETF RFCs.  Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-housley-aaa-key-mgmt-09</draft>
        <is-also>
            <doc-id>BCP0132</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4962</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4963</doc-id>
        <title>IPv4 Reassembly Errors at High Data Rates</title>
        <author>
            <name>J. Heffner</name>
        </author>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>B. Chandler</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet.  At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers.  This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-heffner-frag-harmful-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4963</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4964</doc-id>
        <title>The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular</title>
        <author>
            <name>A. Allen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Holm</name>
        </author>
        <author>
            <name>T. Hallin</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>p-header</kw>
            <kw>oma</kw>
            <kw>open mobile alliance</kw>
            <kw>poc</kw>
        </keywords>
        <abstract><p>This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application.  The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-allen-sipping-poc-p-answer-state-header-05</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4964</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4965</doc-id>
        <title>CableLabs - IETF Standardization Collaboration</title>
        <author>
            <name>J-F. Mule</name>
        </author>
        <author>
            <name>W. Townsley</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IETF CableLabs Collaboration</kw>
            <kw>liaison</kw>
            <kw>Cable Television Laboratories</kw>
            <kw>DOCSIS</kw>
            <kw>PacketCable</kw>
            <kw>OpenCable</kw>
        </keywords>
        <abstract><p>This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mule-ietf-cablelabs-collaboration-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC4965</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4966</doc-id>
        <title>Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status</title>
        <author>
            <name>C. Aoun</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>NAT-PT</kw>
            <kw>v6ops</kw>
        </keywords>
        <abstract><p>This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766.  These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-natpt-to-historic-00</draft>
        <obsoletes>
            <doc-id>RFC2766</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4966</errata-url>
        <doi>10.17487/RFC4966</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4967</doc-id>
        <title>Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>dialstring</kw>
        </keywords>
        <abstract><p>RFC 3966 explicitly states that 'tel' URIs may not represent a dial string.  That leaves no way specify a dial string in a standardized way.  Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string.  This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-rosen-iptel-dialstring-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4967</errata-url>
        <doi>10.17487/RFC4967</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4968</doc-id>
        <title>Analysis of IPv6 Link Models for 802.16 Based Networks</title>
        <author>
            <name>S. Madanapalli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>wimax</kw>
        </keywords>
        <abstract><p>This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios.  This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-16ng-ipv6-link-model-analysis-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>16ng</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4968</errata-url>
        <doi>10.17487/RFC4968</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4969</doc-id>
        <title>IANA Registration for vCard Enumservice</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>enum</kw>
            <kw>e.164</kw>
        </keywords>
        <abstract><p>This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number.</p><p> Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-vcard-06</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4969</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4970</doc-id>
        <title>Extensions to OSPF for Advertising Optional Router Capabilities</title>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>S. Shaffer</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ospfv2</kw>
            <kw>ospfv3</kw>
            <kw>open shortest path first</kw>
            <kw>ri</kw>
            <kw>router information</kw>
            <kw>lsa</kw>
            <kw>link state advertisement</kw>
        </keywords>
        <abstract><p>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain.  This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities.  A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose.  In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID.  In OSPFv3, the RI LSA will be implemented with a new LSA type function code.  In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-cap-11</draft>
        <obsoleted-by>
            <doc-id>RFC7770</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC4970</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4971</doc-id>
        <title>Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Shen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Aggarwal</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>capabilty</kw>
        </keywords>
        <abstract><p>This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-caps-07</draft>
        <obsoleted-by>
            <doc-id>RFC7981</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC4971</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4972</doc-id>
        <title>Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JL. Leroux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Yasukawa</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>P. Mabbey</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>mpls-te</kw>
            <kw>lsp</kw>
            <kw>label switched path</kw>
            <kw>igp</kw>
            <kw>is-is</kw>
            <kw>ospf</kw>
        </keywords>
        <abstract><p>The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs).  This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-automesh-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4972</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4973</doc-id>
        <title>OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>P. Joseph</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>ospf-te</kw>
            <kw>link state advertisement</kw>
            <kw>lsa</kw>
        </keywords>
        <abstract><p>This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF.  OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas.  When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs.  OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths.  OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-srisuresh-ospf-te-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4973</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4974</doc-id>
        <title>Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls</title>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
        </keywords>
        <abstract><p>In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.</p><p> A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).</p><p> This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.</p><p> The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-rsvp-te-call-04</draft>
        <updates>
            <doc-id>RFC3473</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6001</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4974</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4975</doc-id>
        <title>The Message Session Relay Protocol (MSRP)</title>
        <author>
            <name>B. Campbell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Mahy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Jennings</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>instant message</kw>
        </keywords>
        <abstract><p>This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session.  Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-message-sessions-19</draft>
        <updated-by>
            <doc-id>RFC7977</doc-id>
            <doc-id>RFC8591</doc-id>
            <doc-id>RFC8873</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4975</errata-url>
        <doi>10.17487/RFC4975</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4976</doc-id>
        <title>Relay Extensions for the Message Sessions Relay Protocol (MSRP)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>instante message</kw>
            <kw>page-mode</kw>
            <kw>session-mode</kw>
            <kw>relay intermediary</kw>
        </keywords>
        <abstract><p>Two separate models for conveying instant messages have been defined.  Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP.  The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.  This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-msrp-relays-10</draft>
        <updated-by>
            <doc-id>RFC7977</doc-id>
            <doc-id>RFC8553</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4976</errata-url>
        <doi>10.17487/RFC4976</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4977</doc-id>
        <title>Problem Statement: Dual Stack Mobility</title>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>H. Soliman</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mobility management protocol</kw>
            <kw>mipv4</kw>
            <kw>mipv6</kw>
            <kw>mobile ip</kw>
        </keywords>
        <abstract><p>This document discusses the issues associated with mobility management for dual stack mobile nodes.  Currently, two mobility management protocols are defined for IPv4 and IPv6.  Deploying both in a dual stack mobile node introduces a number of problems.  Deployment and operational issues motivate the use of a single mobility management protocol.  This document discusses such motivations.  The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-dsmip-problem-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC4977</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4978</doc-id>
        <title>The IMAP COMPRESS Extension</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet Message Access Protocol</kw>
        </keywords>
        <abstract><p>The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-compress-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4978</errata-url>
        <doi>10.17487/RFC4978</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4979</doc-id>
        <title>IANA Registration for Enumservice 'XMPP'</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>extensible messaging and presence protocol</kw>
            <kw>e.164</kw>
        </keywords>
        <abstract><p>This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol.  This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-xmpp-02</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC4979</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4980</doc-id>
        <title>Analysis of Multihoming in Network Mobility Support</title>
        <author>
            <name>C. Ng</name>
        </author>
        <author>
            <name>T. Ernst</name>
        </author>
        <author>
            <name>E. Paik</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>nemo</kw>
            <kw>ipv6</kw>
            <kw>mobile networks</kw>
        </keywords>
        <abstract><p>This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6.  As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations.  The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support).  Recommendations are offered on how to address these issues.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nemo-multihoming-issues-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>nemo</wg_acronym>
        <doi>10.17487/RFC4980</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4981</doc-id>
        <title>Survey of Research towards Robust Peer-to-Peer Networks: Search Methods</title>
        <author>
            <name>J. Risson</name>
        </author>
        <author>
            <name>T. Moors</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>Peer-to-peer network</kw>
            <kw>Distributed hash table</kw>
            <kw>Structured overlay</kw>
            <kw>Unstructured overlay</kw>
            <kw>Key-based routing</kw>
            <kw>Consistent hashing</kw>
            <kw>Scalable distributed data structure</kw>
            <kw>Dependability</kw>
            <kw>Hypercube</kw>
            <kw>Plaxton tree</kw>
            <kw>de Bruijn graph</kw>
            <kw>Skip graph</kw>
            <kw>Torus</kw>
            <kw>Butterfly network</kw>
            <kw>Vector model</kw>
            <kw>Latent semantic indexing</kw>
        </keywords>
        <abstract><p>The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.</p><p> Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.</p><p> P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-p2prg-survey-search-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC4981</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4982</doc-id>
        <title>Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-bagnulo-multiple-hash-cga-03</draft>
        <updates>
            <doc-id>RFC3972</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4982</errata-url>
        <doi>10.17487/RFC4982</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4983</doc-id>
        <title>Fibre Channel Registered State Change Notification (RSCN) MIB</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>H.K. Vivek</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-RSCN-MIB</kw>
        </keywords>
        <abstract><p>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 management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-rscn-mib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC4983</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4984</doc-id>
        <title>Report from the IAB Workshop on Routing and Addressing</title>
        <author>
            <name>D. Meyer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Fall</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>routing and addressing workshop</kw>
            <kw>routing table growth</kw>
            <kw>addressing architecture</kw>
        </keywords>
        <abstract><p>This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-raws-report-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc4984</errata-url>
        <doi>10.17487/RFC4984</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4985</doc-id>
        <title>Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>othername</kw>
        </keywords>
        <abstract><p>This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-srvsan-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4985</errata-url>
        <doi>10.17487/RFC4985</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4986</doc-id>
        <title>Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover</title>
        <author>
            <name>H. Eland</name>
        </author>
        <author>
            <name>R. Mundy</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>S. Krishnaswamy</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>dns signed zone</kw>
        </keywords>
        <abstract><p>Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones.  For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors.  For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers.  This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dnsext-rollover-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC4986</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4987</doc-id>
        <title>TCP SYN Flooding Attacks and Common Mitigations</title>
        <author>
            <name>W. Eddy</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TCP SYN Flood</kw>
            <kw>TCP SYN Cookies</kw>
            <kw>denial-of-service</kw>
            <kw>DoS</kw>
        </keywords>
        <abstract><p>This document describes TCP SYN flooding attacks, which have been well-known to the community for several years.  Various countermeasures against these attacks, and the trade-offs of each, are described.  This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-syn-flood-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4987</errata-url>
        <doi>10.17487/RFC4987</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4988</doc-id>
        <title>Mobile IPv4 Fast Handovers</title>
        <author>
            <name>R. Koodli</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>mip4</kw>
            <kw>delay</kw>
            <kw>packet loss</kw>
            <kw>movement detection</kw>
            <kw>ip address configuration</kw>
            <kw>loation update latency</kw>
            <kw>care-of address</kw>
            <kw>care of address</kw>
            <kw>coa</kw>
        </keywords>
        <abstract><p>This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations.  Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover.  For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mip4-fmipv4-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC4988</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4989</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC4990</doc-id>
        <title>Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks</title>
        <author>
            <name>K. Shiomoto</name>
        </author>
        <author>
            <name>R. Papneja</name>
        </author>
        <author>
            <name>R. Rabbat</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>address field</kw>
            <kw>identifier field</kw>
        </keywords>
        <abstract><p>This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.</p><p> The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.</p><p> This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-addressing-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC4990</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4991</doc-id>
        <title>A Common Schema for Internet Registry Information Service Transfer Protocols</title>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>iris</kw>
            <kw>xml</kw>
        </keywords>
        <abstract><p>This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics.  It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-crisp-iris-common-transport-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4991</errata-url>
        <doi>10.17487/RFC4991</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4992</doc-id>
        <title>XML Pipelining with Chunks for the Internet Registry Information Service</title>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>transport control protocol</kw>
            <kw>iris</kw>
        </keywords>
        <abstract><p>This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS).  Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-crisp-iris-xpc-06</draft>
        <updates>
            <doc-id>RFC3981</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4992</errata-url>
        <doi>10.17487/RFC4992</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4993</doc-id>
        <title>A Lightweight UDP Transfer Protocol for the Internet Registry Information Service</title>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>iris</kw>
        </keywords>
        <abstract><p>This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS).  This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-crisp-iris-lwz-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4993</errata-url>
        <doi>10.17487/RFC4993</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4994</doc-id>
        <title>DHCPv6 Relay Agent Echo Request Option</title>
        <author>
            <name>S. Zeng</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>J. Brzozowski</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
            <kw>relay agent option</kw>
        </keywords>
        <abstract><p>This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-ero-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC4994</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4995</doc-id>
        <title>The RObust Header Compression (ROHC) Framework</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>K. Sandlund</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.</p><p> The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-rfc3095bis-framework-04</draft>
        <obsoleted-by>
            <doc-id>RFC5795</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4995</errata-url>
        <doi>10.17487/RFC4995</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4996</doc-id>
        <title>RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)</title>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>K. Sandlund</name>
        </author>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>M. West</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.</p><p> ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-tcp-16</draft>
        <obsoleted-by>
            <doc-id>RFC6846</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4996</errata-url>
        <doi>10.17487/RFC4996</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4997</doc-id>
        <title>Formal Notation for RObust Header Compression (ROHC-FN)</title>
        <author>
            <name>R. Finking</name>
        </author>
        <author>
            <name>G. Pelletier</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>Robust Header Compression - Formal Notation</kw>
        </keywords>
        <abstract><p>This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework.  ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-formal-notation-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC4997</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4998</doc-id>
        <title>Evidence Record Syntax (ERS)</title>
        <author>
            <name>T. Gondrom</name>
        </author>
        <author>
            <name>R. Brandner</name>
        </author>
        <author>
            <name>U. Pordesch</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>long-term archive</kw>
            <kw>security</kw>
            <kw>timestamp</kw>
            <kw>evidence record</kw>
            <kw>archive timestamp</kw>
        </keywords>
        <abstract><p>In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time.  This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ltans-ers-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ltans</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc4998</errata-url>
        <doi>10.17487/RFC4998</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC4999</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5000</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>RFC Editor</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.</p><p> For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.</p></abstract>
        <obsoletes>
            <doc-id>RFC3700</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7100</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5000</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5001</doc-id>
        <title>DNS Name Server Identifier (NSID) Option</title>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>domain name space</kw>
            <kw>namespace</kw>
        </keywords>
        <abstract><p>With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query.  While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself.  This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-nsid-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5001</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5002</doc-id>
        <title>The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>G. Blanco</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>3gpp</kw>
            <kw>ims</kw>
            <kw>ip multimedia subsystem</kw>
        </keywords>
        <abstract><p>This document specifies the SIP P-Profile-Key P-header.  This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-camarillo-sipping-profile-key-02</draft>
        <updated-by>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5002</errata-url>
        <doi>10.17487/RFC5002</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5003</doc-id>
        <title>Attachment Individual Identifier (AII) Types for Aggregation</title>
        <author>
            <name>C. Metz</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>F. Balus</name>
        </author>
        <author>
            <name>J. Sugimoto</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>tlv</kw>
            <kw>pseudowire</kw>
        </keywords>
        <abstract><p>The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs).  This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery.  It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-aii-aggregate-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5003</errata-url>
        <doi>10.17487/RFC5003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5004</doc-id>
        <title>Avoid BGP Best Path Transitions from One External to Another</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>S. Sangli</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions.  The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-avoid-transition-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC5004</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5005</doc-id>
        <title>Feed Paging and Archiving</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>atom</kw>
            <kw>rss</kw>
        </keywords>
        <abstract><p>This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents.  This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-nottingham-atompub-feed-history-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5005</errata-url>
        <doi>10.17487/RFC5005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5006</doc-id>
        <title>IPv6 Router Advertisement Option for DNS Configuration</title>
        <author>
            <name>J. Jeong</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>L. Beloeil</name>
        </author>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>domain namespace</kw>
        </keywords>
        <abstract><p>This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-jeong-dnsop-ipv6-dns-discovery-12</draft>
        <obsoleted-by>
            <doc-id>RFC6106</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5006</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5007</doc-id>
        <title>DHCPv6 Leasequery</title>
        <author>
            <name>J. Brzozowski</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>S. Zeng</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>dhc</kw>
            <kw>dhcp</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server.  This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior.  This document extends DHCPv6. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-leasequery-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5007</errata-url>
        <doi>10.17487/RFC5007</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5008</doc-id>
        <title>Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>nsa</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-housley-smime-suite-b-02</draft>
        <obsoleted-by>
            <doc-id>RFC6318</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5008</errata-url>
        <doi>10.17487/RFC5008</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5009</doc-id>
        <title>Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media</title>
        <author>
            <name>R. Ejzak</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IMS</kw>
            <kw>NGN</kw>
            <kw>ETSI TISPAN</kw>
            <kw>Gating</kw>
            <kw>Cut-through</kw>
            <kw>Call progress</kw>
            <kw>Charging</kw>
            <kw>PSTN</kw>
            <kw>Interworking</kw>
            <kw>Gateway</kw>
            <kw>Ringback</kw>
            <kw>Trust domain</kw>
        </keywords>
        <abstract><p>This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS).  This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ejzak-sipping-p-em-auth-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5009</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5010</doc-id>
        <title>The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption</title>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>M. Normoyle</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>unicast flag</kw>
            <kw>broadcast flag</kw>
        </keywords>
        <abstract><p>This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet.  One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet.  This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-relay-agent-flags-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC5010</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5011</doc-id>
        <title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title>
        <author>
            <name>M. StJohns</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>n-1 key</kw>
            <kw>n keys</kw>
        </keywords>
        <abstract><p>This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</p><p> This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-trustupdate-timers-06</draft>
        <is-also>
            <doc-id>STD0074</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5011</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5012</doc-id>
        <title>Requirements for Emergency Context Resolution with Internet Technologies</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>R. Marshall</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>emergency calling</kw>
            <kw>ecrit</kw>
        </keywords>
        <abstract><p>This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ecrit-requirements-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5012</errata-url>
        <doi>10.17487/RFC5012</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5013</doc-id>
        <title>The Dublin Core Metadata Element Set</title>
        <author>
            <name>J. Kunze</name>
        </author>
        <author>
            <name>T. Baker</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>resource description</kw>
            <kw>object descriptors</kw>
            <kw>digital library collections</kw>
        </keywords>
        <abstract><p>This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kunze-rfc2413bis-07</draft>
        <obsoletes>
            <doc-id>RFC2413</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5013</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5014</doc-id>
        <title>IPv6 Socket API for Source Address Selection</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>J. Laganier</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>getaddrinfo()cga</kw>
            <kw>cryptographically generated address</kw>
        </keywords>
        <abstract><p>The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API.  However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents.  This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm.  The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication.  It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-chakrabarti-ipv6-addrselect-api-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5014</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5015</doc-id>
        <title>Bidirectional Protocol Independent Multicast (BIDIR-PIM)</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <author>
            <name>T. Speakman</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>pim</kw>
            <kw>sparse-mode</kw>
            <kw>shared trees</kw>
        </keywords>
        <abstract><p>This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers.  Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology.  With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state.  The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-bidir-09</draft>
        <updated-by>
            <doc-id>RFC8736</doc-id>
            <doc-id>RFC9436</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5015</errata-url>
        <doi>10.17487/RFC5015</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5016</doc-id>
        <title>Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol</title>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>cryptographic</kw>
        </keywords>
        <abstract><p>DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle.  A related mechanism will allow an administrator to publish various statements about their DKIM signing practices.  This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dkim-ssp-requirements-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <doi>10.17487/RFC5016</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5017</doc-id>
        <title>MIB Textual Conventions for Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>D. McWalter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>URI-TC-MIB</kw>
        </keywords>
        <abstract><p>This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs).  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mcwalter-uri-mib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5017</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5018</doc-id>
        <title>Connection Establishment in the Binary Floor Control Protocol (BFCP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>floor control server</kw>
            <kw>tls</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange.  Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xcon-bfcp-connection-05</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC5018</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5019</doc-id>
        <title>The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments</title>
        <author>
            <name>A. Deacon</name>
        </author>
        <author>
            <name>R. Hurst</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>OCSP</kw>
            <kw>Online Certificate</kw>
            <kw>Status Protocol</kw>
            <kw>certificate status</kw>
            <kw>http caching</kw>
            <kw>http proxies</kw>
            <kw>efficient</kw>
            <kw>cacheable</kw>
            <kw>pre-produced</kw>
        </keywords>
        <abstract><p>This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-lightweight-ocsp-profile-11</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5019</errata-url>
        <doi>10.17487/RFC5019</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5020</doc-id>
        <title>The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>x.500</kw>
        </keywords>
        <abstract><p>This document describes the Lightweight Directory Access Protocol (LDAP) / X.500 'entryDN' operational attribute.  The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-entrydn-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5020</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5021</doc-id>
        <title>Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports.  The mechanism uses the reserved high-bit in the length field.  It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-tcp-expansion-02</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC5021</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5022</doc-id>
        <title>Media Server Control Markup Language (MSCML) and Protocol</title>
        <author>
            <name>J. Van Dyke</name>
        </author>
        <author>
            <name>E. Burger</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Spitzer</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>ivr</kw>
            <kw>interactive voice response</kw>
        </keywords>
        <abstract><p>Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions.  MSCML presents an application-level control model, as opposed to device-level control models.  One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.  This memo provides information for the Internet community.</p></abstract>
        <obsoletes>
            <doc-id>RFC4722</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5022</errata-url>
        <doi>10.17487/RFC5022</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5023</doc-id>
        <title>The Atom Publishing Protocol</title>
        <author>
            <name>J. Gregorio</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. de hOra</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>atompub</kw>
            <kw>http transfer</kw>
            <kw>atom syndication format</kw>
        </keywords>
        <abstract><p>The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources.  The protocol is based on HTTP transfer of Atom-formatted representations.  The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-atompub-protocol-17</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>atompub</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5023</errata-url>
        <doi>10.17487/RFC5023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5024</doc-id>
        <title>ODETTE File Transfer Protocol 2.0</title>
        <author>
            <name>I. Friend</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>135</page-count>
        <abstract><p>This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.</p><p> The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.</p><p> The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-friend-oftp2-04</draft>
        <obsoletes>
            <doc-id>RFC2204</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5024</errata-url>
        <doi>10.17487/RFC5024</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5025</doc-id>
        <title>Presence Authorization Rules</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>presence systems</kw>
            <kw>authorization policies</kw>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>Authorization is a key function in presence systems.  Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when.  This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules.  Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-presence-rules-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5025</errata-url>
        <doi>10.17487/RFC5025</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5026</doc-id>
        <title>Mobile IPv6 Bootstrapping in Split Scenario</title>
        <author>
            <name>G. Giaretta</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>mip6</kw>
            <kw>bootstrapping problem statement</kw>
        </keywords>
        <abstract><p>A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service.  RFC 3775 requires that some or all of these are statically configured.  This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node.  The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640.  The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access.  The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-bootstrapping-split-07</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC5026</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5027</doc-id>
        <title>Security Preconditions for Session Description Protocol (SDP) Media Streams</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>DTLS</kw>
            <kw>DTLS-SRTP</kw>
            <kw>TLS</kw>
            <kw>MIKEY</kw>
            <kw>Security Descriptions</kw>
            <kw>SRTP</kw>
        </keywords>
        <abstract><p>This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032.  A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-securityprecondition-04</draft>
        <updates>
            <doc-id>RFC3312</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC5027</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5028</doc-id>
        <title>A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>'im:'</kw>
            <kw>uri</kw>
            <kw>uniform resource identifier</kw>
        </keywords>
        <abstract><p>This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM).  Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-im-service-03</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5028</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5029</doc-id>
        <title>Definition of an IS-IS Link Attribute Sub-TLV</title>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>link-attributes</kw>
            <kw>tlv 22</kw>
        </keywords>
        <abstract><p>This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-link-attr-03</draft>
        <updated-by>
            <doc-id>RFC9650</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5029</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5030</doc-id>
        <title>Mobile IPv4 RADIUS Requirements</title>
        <author>
            <name>M. Nakhjiri</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>mip</kw>
            <kw>mipv4</kw>
        </keywords>
        <abstract><p>This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4.  The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip4-radius-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC5030</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5031</doc-id>
        <title>A Uniform Resource Name (URN) for Emergency and Other Well-Known Services</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>urn</kw>
            <kw>ecrit</kw>
        </keywords>
        <abstract><p>The content of many communication services depends on the context, such as the user's location.  We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified.  Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ecrit-service-urn-07</draft>
        <updated-by>
            <doc-id>RFC7163</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5031</errata-url>
        <doi>10.17487/RFC5031</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5032</doc-id>
        <title>WITHIN Search Extension to the IMAP Protocol</title>
        <author>
            <name>E. Burger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>imap search</kw>
            <kw>older</kw>
            <kw>younger</kw>
        </keywords>
        <abstract><p>This document describes the WITHIN extension to IMAP SEARCH.  IMAP SEARCH returns messages whose internal date is within or outside a specified interval.  The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date.  WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-search-within-05</draft>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5032</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5033</doc-id>
        <title>Specifying New Congestion Control Algorithms</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks).  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-tsvwg-cc-alt-04</draft>
        <obsoleted-by>
            <doc-id>RFC9743</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5033</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5034</doc-id>
        <title>The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism</title>
        <author>
            <name>R. Siemborski</name>
        </author>
        <author>
            <name>A. Menon-Sen</name>
        </author>
        <date>
            <month>July</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>POP3-AUTH</kw>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract><p>This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.</p><p> This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-siemborski-rfc1734bis-11</draft>
        <obsoletes>
            <doc-id>RFC1734</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2449</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5035</doc-id>
        <title>Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>validation</kw>
            <kw>signature</kw>
            <kw>certificate</kw>
        </keywords>
        <abstract><p>In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1.  This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-escertid-06</draft>
        <updates>
            <doc-id>RFC2634</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5035</errata-url>
        <doi>10.17487/RFC5035</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5036</doc-id>
        <title>LDP Specification</title>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Minei</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Thomas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>135</page-count>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031.  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]</p></abstract>
        <draft>draft-ietf-mpls-rfc3036bis-04</draft>
        <obsoletes>
            <doc-id>RFC3036</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6720</doc-id>
            <doc-id>RFC6790</doc-id>
            <doc-id>RFC7358</doc-id>
            <doc-id>RFC7552</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5036</errata-url>
        <doi>10.17487/RFC5036</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5037</doc-id>
        <title>Experience with the Label Distribution Protocol (LDP)</title>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Minei</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Thomas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol).  Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-ldp-experience-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5037</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5038</doc-id>
        <title>The Label Distribution Protocol (LDP) Implementation Survey Results</title>
        <author>
            <name>B. Thomas</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpls</kw>
            <kw>lsr</kw>
            <kw>label switched routers</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops.  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 (as described in RFC 3036) , by which one LSR informs another of label bindings it has made.  One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths.  This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-ldp-survey2002-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5038</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5039</doc-id>
        <title>The Session Initiation Protocol (SIP) and Spam</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email.  Unfortunately, spam is not limited to email.  It can affect any system that enables user-to-user communications.  The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications.  Therefore, it is susceptible to spam, just as email is.  In this document, we analyze the problem of spam in SIP.  We first identify the ways in which the problem is the same and the ways in which it is different from email.  We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-spam-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5039</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5040</doc-id>
        <title>A Remote Direct Memory Access Protocol Specification</title>
        <author>
            <name>R. Recio</name>
        </author>
        <author>
            <name>B. Metzler</name>
        </author>
        <author>
            <name>P. Culley</name>
        </author>
        <author>
            <name>J. Hilland</name>
        </author>
        <author>
            <name>D. Garcia</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>rdmap</kw>
            <kw>ddp</kw>
            <kw>direct data placement protocol</kw>
        </keywords>
        <abstract><p>This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol).  RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies.  It also enables a kernel bypass implementation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rddp-rdmap-07</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <doi>10.17487/RFC5040</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5041</doc-id>
        <title>Direct Data Placement over Reliable Transports</title>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>J. Pinkerton</name>
        </author>
        <author>
            <name>R. Recio</name>
        </author>
        <author>
            <name>P. Culley</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>ddp</kw>
            <kw>cpu</kw>
        </keywords>
        <abstract><p>The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers.  This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rddp-ddp-07</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <doi>10.17487/RFC5041</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5042</doc-id>
        <title>Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security</title>
        <author>
            <name>J. Pinkerton</name>
        </author>
        <author>
            <name>E. Deleganes</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>rdma network interface card</kw>
            <kw>rnic</kw>
        </keywords>
        <abstract><p>This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP).  It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP.  The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system.  Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers.  Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rddp-security-10</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <doi>10.17487/RFC5042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5043</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation</title>
        <author>
            <name>C. Bestler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Stewart</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>lower layer protocol</kw>
            <kw>llp</kw>
        </keywords>
        <abstract><p>This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rddp-sctp-07</draft>
        <updated-by>
            <doc-id>RFC6581</doc-id>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <doi>10.17487/RFC5043</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5044</doc-id>
        <title>Marker PDU Aligned Framing for TCP Specification</title>
        <author>
            <name>P. Culley</name>
        </author>
        <author>
            <name>U. Elzur</name>
        </author>
        <author>
            <name>R. Recio</name>
        </author>
        <author>
            <name>S. Bailey</name>
        </author>
        <author>
            <name>J. Carrier</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>mpa</kw>
            <kw>adaaptation layer</kw>
            <kw>ddp</kw>
            <kw>direct data placement protocol</kw>
            <kw>transmission</kw>
        </keywords>
        <abstract><p>Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041.  It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires.  MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations.  MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rddp-mpa-08</draft>
        <updated-by>
            <doc-id>RFC6581</doc-id>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5044</errata-url>
        <doi>10.17487/RFC5044</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5045</doc-id>
        <title>Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)</title>
        <author>
            <name>C. Bestler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Coene</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>rdmap</kw>
        </keywords>
        <abstract><p>This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).  It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rddp-applicability-08</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rddp</wg_acronym>
        <doi>10.17487/RFC5045</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5046</doc-id>
        <title>Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)</title>
        <author>
            <name>M. Ko</name>
        </author>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <author>
            <name>J. Hufferd</name>
        </author>
        <author>
            <name>U. Elzur</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>P. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>rdma data transfer</kw>
        </keywords>
        <abstract><p>Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite.  An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies.  This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-iser-06</draft>
        <obsoleted-by>
            <doc-id>RFC7145</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC5046</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5047</doc-id>
        <title>DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)</title>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <author>
            <name>J. Hufferd</name>
        </author>
        <author>
            <name>J. Satran</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>scsi transport protocol</kw>
            <kw>tcp/ip</kw>
        </keywords>
        <abstract><p>The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP.  Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports.  While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols.  Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself.  This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric.  It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ips-iwarp-da-05</draft>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC5047</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5048</doc-id>
        <title>Internet Small Computer System Interface (iSCSI) Corrections and Clarifications</title>
        <author>
            <name>M. Chadalapaka</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>scsi</kw>
            <kw>iscsi protocol</kw>
        </keywords>
        <abstract><p>The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP.  RFC 3720 defines the iSCSI protocol.  This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers.  This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ips-iscsi-impl-guide-09</draft>
        <obsoleted-by>
            <doc-id>RFC7143</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3720</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ips</wg_acronym>
        <doi>10.17487/RFC5048</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5049</doc-id>
        <title>Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>R. Price</name>
        </author>
        <author>
            <name>G. Camarillo</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP.  Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-sigcomp-sip-08</draft>
        <updates>
            <doc-id>RFC3486</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC5049</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5050</doc-id>
        <title>Bundle Protocol Specification</title>
        <author>
            <name>K. Scott</name>
        </author>
        <author>
            <name>S. Burleigh</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>delay tolerant networking</kw>
            <kw>dtn</kw>
            <kw>dtnrg</kw>
            <kw>exchange of messages</kw>
        </keywords>
        <abstract><p>This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).</p><p> This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-bundle-spec-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5050</errata-url>
        <doi>10.17487/RFC5050</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5051</doc-id>
        <title>i;unicode-casemap - Simple Unicode Collation Algorithm</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>unicode strings</kw>
            <kw>i;ascii-casemap</kw>
        </keywords>
        <abstract><p>This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings.  It provides equality, substring, and ordering operations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-crispin-collation-unicasemap-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5051</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5052</doc-id>
        <title>Forward Error Correction (FEC) Building Block</title>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>bulk data transfer</kw>
        </keywords>
        <abstract><p>This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast.  This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information.  Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered.  The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.  The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined.  The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content.  This document obsoletes RFC 3452. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-fec-bb-revised-07</draft>
        <obsoletes>
            <doc-id>RFC3452</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5052</errata-url>
        <doi>10.17487/RFC5052</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5053</doc-id>
        <title>Raptor Forward Error Correction Scheme for Object Delivery</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>A. Shokrollahi</name>
        </author>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>fec</kw>
            <kw>fec encoding</kw>
            <kw>raptor code</kw>
        </keywords>
        <abstract><p>This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.</p><p> Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.</p><p> The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-raptor-object-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC5053</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5054</doc-id>
        <title>Using the Secure Remote Password (SRP) Protocol for TLS Authentication</title>
        <author>
            <name>D. Taylor</name>
        </author>
        <author>
            <name>T. Wu</name>
        </author>
        <author>
            <name>N. Mavrogiannopoulos</name>
        </author>
        <author>
            <name>T. Perrin</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>secure remote password protocol</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tls-srp-14</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5054</errata-url>
        <doi>10.17487/RFC5054</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5055</doc-id>
        <title>Server-Based Certificate Validation Protocol (SCVP)</title>
        <author>
            <name>T. Freeman</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>A. Malpani</name>
        </author>
        <author>
            <name>D. Cooper</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>certification path construction</kw>
            <kw>certification path validation</kw>
        </keywords>
        <abstract><p>The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server.  The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors.  It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-scvp-33</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC5055</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5056</doc-id>
        <title>On the Use of Channel Bindings to Secure Channels</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
        </keywords>
        <abstract><p>The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.</p><p> This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-williams-on-channel-binding-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5056</errata-url>
        <doi>10.17487/RFC5056</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5057</doc-id>
        <title>Multiple Dialog Usages in the Session Initiation Protocol</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.</p><p> This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.</p><p> This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-dialogusage-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5057</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5058</doc-id>
        <title>Explicit Multicast (Xcast) Concepts and Options</title>
        <author>
            <name>R. Boivie</name>
        </author>
        <author>
            <name>N. Feldman</name>
        </author>
        <author>
            <name>Y. Imai</name>
        </author>
        <author>
            <name>W. Livens</name>
        </author>
        <author>
            <name>D. Ooms</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>explicit multi-unicast</kw>
        </keywords>
        <abstract><p>While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.</p><p> This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ooms-xcast-basic-spec-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5058</errata-url>
        <doi>10.17487/RFC5058</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5059</doc-id>
        <title>Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)</title>
        <author>
            <name>N. Bhaskar</name>
        </author>
        <author>
            <name>A. Gall</name>
        </author>
        <author>
            <name>J. Lingard</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>rendezvous point</kw>
            <kw>rp</kw>
            <kw>multicast router</kw>
        </keywords>
        <abstract><p>This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group.  BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function.  The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-sm-bsr-12</draft>
        <obsoletes>
            <doc-id>RFC2362</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4601</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8736</doc-id>
            <doc-id>RFC9436</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5059</errata-url>
        <doi>10.17487/RFC5059</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5060</doc-id>
        <title>Protocol Independent Multicast MIB</title>
        <author>
            <name>R. Sivaramu</name>
        </author>
        <author>
            <name>J. Lingard</name>
        </author>
        <author>
            <name>D. McWalter</name>
        </author>
        <author>
            <name>B. Joshi</name>
        </author>
        <author>
            <name>A. Kessler</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>PIM</kw>
            <kw>PIM-SM</kw>
            <kw>BIDIR-PIM</kw>
            <kw>PIM-DM</kw>
            <kw>Multicast Routing</kw>
            <kw>PIM-STD-MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>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) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode).  This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap.  This document does not obsolete RFC 2934. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-mib-v2-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5060</errata-url>
        <doi>10.17487/RFC5060</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5061</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>S. Maruyama</name>
        </author>
        <author>
            <name>M. Kozuka</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
        </keywords>
        <abstract><p>A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures.  Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures.  This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-addip-sctp-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5061</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5062</doc-id>
        <title>Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document describes certain security threats to SCTP.  It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460).  These techniques are included in RFC 4960, which obsoletes RFC 2960.  It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-sctpthreat-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5062</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5063</doc-id>
        <title>Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart</title>
        <author>
            <name>A. Satyanarayana</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Rahman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>nodal faults</kw>
            <kw>rsvp hello</kw>
            <kw>state recovery</kw>
        </keywords>
        <abstract><p>This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.</p><p> Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.</p><p> The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.</p><p> These extensions are not used to create or restore data plane state.</p><p> The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rsvp-restart-ext-09</draft>
        <updates>
            <doc-id>RFC2961</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5063</errata-url>
        <doi>10.17487/RFC5063</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5064</doc-id>
        <title>The Archived-At Message Header Field</title>
        <author>
            <name>M. Duerst</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-duerst-archived-at-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5064</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5065</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>August</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>tcp/ip</kw>
            <kw>full mesh</kw>
        </keywords>
        <abstract><p>The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.</p><p> This document describes an extension to BGP that 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.</p><p> This document obsoletes RFC 3065. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-rfc3065bis-06</draft>
        <obsoletes>
            <doc-id>RFC3065</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9774</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5065</errata-url>
        <doi>10.17487/RFC5065</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5066</doc-id>
        <title>Ethernet in the First Mile Copper (EFMCu) Interfaces MIB</title>
        <author>
            <name>E. Beili</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>Textual Conventions</kw>
            <kw>2BASE-TL</kw>
            <kw>10PASS-TS</kw>
            <kw>802.3ah</kw>
            <kw>EFM</kw>
            <kw>PAF</kw>
            <kw>PME</kw>
        </keywords>
        <abstract><p>This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets.  This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005).  In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hubmib-efm-cu-mib-08</draft>
        <updated-by>
            <doc-id>RFC7124</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>hubmib</wg_acronym>
        <doi>10.17487/RFC5066</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5067</doc-id>
        <title>Infrastructure ENUM Requirements</title>
        <author>
            <name>S. Lind</name>
        </author>
        <author>
            <name>P. Pfautz</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>e.164 number mapping</kw>
            <kw>carrier</kw>
        </keywords>
        <abstract><p>This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-enum-infrastructure-enum-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5067</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5068</doc-id>
        <title>Email Submission Operations: Access and Accountability Requirements</title>
        <author>
            <name>C. Hutzler</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>E. Allman</name>
        </author>
        <author>
            <name>T. Finch</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>spam</kw>
            <kw>email abuse</kw>
            <kw>phishing</kw>
            <kw>email</kw>
            <kw>e-mail</kw>
            <kw>service</kw>
            <kw>mime</kw>
            <kw>rfc2822</kw>
            <kw>rfc 2822</kw>
            <kw>rfc822</kw>
            <kw>rfc 822</kw>
            <kw>rfc2821</kw>
            <kw>rfc 2821</kw>
            <kw>rfc821</kw>
            <kw>rfc 821</kw>
            <kw>architecture</kw>
            <kw>mta</kw>
            <kw>mua</kw>
            <kw>msa</kw>
            <kw>mda</kw>
            <kw>user</kw>
            <kw>delivery</kw>
            <kw>relay</kw>
            <kw>header</kw>
            <kw>gateway agent</kw>
            <kw>sieve</kw>
            <kw>dsn</kw>
            <kw>mdn</kw>
            <kw>tussle</kw>
            <kw>mhs</kw>
            <kw>mail handling service</kw>
            <kw>message transfer agent</kw>
            <kw>message user agent</kw>
            <kw>mail submission agent</kw>
            <kw>mail delivery agent</kw>
        </keywords>
        <abstract><p>Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.</p><p> Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-hutzler-spamops-08</draft>
        <updated-by>
            <doc-id>RFC8314</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0134</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5068</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5069</doc-id>
        <title>Security Threats and Requirements for Emergency Call Marking and Mapping</title>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>M. Shanmugam</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ecrit</kw>
            <kw>public safety answering points</kw>
            <kw>pasp</kw>
        </keywords>
        <abstract><p>This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.</p><p> Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ecrit-security-threats-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC5069</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5070</doc-id>
        <title>The Incident Object Description Exchange Format</title>
        <author>
            <name>R. Danyliw</name>
        </author>
        <author>
            <name>J. Meijer</name>
        </author>
        <author>
            <name>Y. Demchenko</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>incident data format</kw>
            <kw>compuer security incident</kw>
            <kw>computer security incident response team</kw>
            <kw>csirt</kw>
            <kw>cert</kw>
            <kw>security data sharing</kw>
            <kw>computer network defense service provider</kw>
            <kw>cndsp</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents.  This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-inch-iodef-14</draft>
        <obsoleted-by>
            <doc-id>RFC7970</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6685</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>inch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5070</errata-url>
        <doi>10.17487/RFC5070</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5071</doc-id>
        <title>Dynamic Host Configuration Protocol Options Used by PXELINUX</title>
        <author>
            <name>D. Hankins</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>dhcp</kw>
            <kw>dhcp option codes</kw>
        </keywords>
        <abstract><p>This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dhc-pxelinux-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC5071</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5072</doc-id>
        <title>IP Version 6 over PPP</title>
        <author>
            <name>S. Varada</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Haskins</name>
        </author>
        <author>
            <name>E. Allen</name>
        </author>
        <date>
            <month>September</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPv6-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>The Point-to-Point Protocol (PPP) 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.</p><p> This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.</p><p> It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.</p><p> This document obsoletes RFC 2472. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-over-ppp-v2-03</draft>
        <obsoletes>
            <doc-id>RFC2472</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC5072</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5073</doc-id>
        <title>IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities</title>
        <author>
            <name>J.P. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J.L. Le Roux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>interior gateway protocol</kw>
        </keywords>
        <abstract><p>It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP.  This requires advertising these capabilities within the Interior Gateway Protocol (IGP).  For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-te-node-cap-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5073</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5074</doc-id>
        <title>DNSSEC Lookaside Validation (DLV)</title>
        <author>
            <name>S. Weiler</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>dns security</kw>
            <kw>trust anchors</kw>
        </keywords>
        <abstract><p>DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain.  It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-weiler-dnssec-dlv-04</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5075</doc-id>
        <title>IPv6 Router Advertisement Flags Option</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>neighbor discovery protocol</kw>
            <kw>ndp</kw>
            <kw>expanded flags option</kw>
            <kw>efo</kw>
            <kw>ndp  router advertisement message</kw>
        </keywords>
        <abstract><p>The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags.  Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field.  This document defines an option to the Router Advertisement message that expands the available number of flag bits available. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-ra-flags-option-02</draft>
        <obsoleted-by>
            <doc-id>RFC5175</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5075</errata-url>
        <doi>10.17487/RFC5075</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5076</doc-id>
        <title>ENUM Validation Information Mapping for the Extensible Provisioning Protocol</title>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>epp</kw>
            <kw>validation process</kw>
            <kw>e.164</kw>
            <kw>enum</kw>
            <kw>enum domain name</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on.  Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-validation-epp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5077</doc-id>
        <title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>H. Zhou</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state.  The TLS server encapsulates the session state into a ticket and forwards it to the client.  The client can subsequently resume a session using the obtained ticket.  This document obsoletes RFC 4507. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-salowey-tls-rfc4507bis-01</draft>
        <obsoletes>
            <doc-id>RFC4507</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8446</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8447</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5077</errata-url>
        <doi>10.17487/RFC5077</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5078</doc-id>
        <title>IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline</title>
        <author>
            <name>S. Dawkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet Architecture Board</kw>
            <kw>Engineering Steering Group</kw>
            <kw>nomcom</kw>
        </keywords>
        <abstract><p>RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in the NomCom process that meets the minimum normative requirements for the process.  Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier.  This document restructures the sample timeline, but makes no normative process changes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dawkins-nomcom-start-earlier-02</draft>
        <obsoleted-by>
            <doc-id>RFC7437</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3777</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5079</doc-id>
        <title>Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>anonymous calls</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) allows for users to make anonymous calls.  However, users receiving such calls have the right to reject them because they are anonymous.  SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous.  Such an indication is useful to allow the call to be retried without anonymity.  This specification defines a new SIP response code for this purpose. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-acr-code-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5079</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5080</doc-id>
        <title>Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes</title>
        <author>
            <name>D. Nelson</name>
        </author>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes.  Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-fixes-08</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
            <doc-id>RFC2866</doc-id>
            <doc-id>RFC2869</doc-id>
            <doc-id>RFC3579</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5080</errata-url>
        <doi>10.17487/RFC5080</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5081</doc-id>
        <title>Using OpenPGP Keys for Transport Layer Security (TLS) Authentication</title>
        <author>
            <name>N. Mavrogiannopoulos</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>tls handshake protocol</kw>
            <kw>handshake</kw>
        </keywords>
        <abstract><p>This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format.  The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tls-openpgp-keys-11</draft>
        <obsoleted-by>
            <doc-id>RFC6091</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC5081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5082</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>
        <author>
            <name>P. Savola</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>October</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>time to live</kw>
            <kw>packet hop limit</kw>
        </keywords>
        <abstract><p>The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols.  This document generalizes this technique.  This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rtgwg-rfc3682bis-10</draft>
        <obsoletes>
            <doc-id>RFC3682</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC5082</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5083</doc-id>
        <title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>encryption mode</kw>
        </keywords>
        <abstract><p>This document describes an additional content type for the Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data content type is intended for use with authenticated encryption modes.  All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-cms-auth-enveloped-06</draft>
        <updates>
            <doc-id>RFC3852</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5083</errata-url>
        <doi>10.17487/RFC5083</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5084</doc-id>
        <title>Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>authenticated encryption algorithm</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-cms-aes-ccm-and-gcm-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5084</errata-url>
        <doi>10.17487/RFC5084</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5085</doc-id>
        <title>Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>pw</kw>
        </keywords>
        <abstract><p>This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel.  VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-vccv-15</draft>
        <updated-by>
            <doc-id>RFC5586</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5085</errata-url>
        <doi>10.17487/RFC5085</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5086</doc-id>
        <title>Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)</title>
        <author>
            <name>A. Vainshtein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Sasson</name>
        </author>
        <author>
            <name>E. Metz</name>
        </author>
        <author>
            <name>T. Frost</name>
        </author>
        <author>
            <name>P. Pate</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>nxds0</kw>
            <kw>psn</kw>
        </keywords>
        <abstract><p>This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs).  In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pwe3-cesopsn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5086</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5087</doc-id>
        <title>Time Division Multiplexing over IP (TDMoIP)</title>
        <author>
            <name>Y(J). Stein</name>
        </author>
        <author>
            <name>R. Shashoua</name>
        </author>
        <author>
            <name>R. Insler</name>
        </author>
        <author>
            <name>M. Anavi</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>TDM</kw>
            <kw>pseudowire</kw>
            <kw>PWE3</kw>
            <kw>TDMoIP</kw>
            <kw>structure-aware TDM emulation</kw>
        </keywords>
        <abstract><p>Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs).  Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport.  Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation.  Accessibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pwe3-tdmoip-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5087</errata-url>
        <doi>10.17487/RFC5087</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5088</doc-id>
        <title>OSPF Protocol Extensions for Path Computation Element (PCE) Discovery</title>
        <author>
            <name>JL. Le Roux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ikejiri</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>pcc</kw>
            <kw>path computation client</kw>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.  When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding.  For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-disco-proto-ospf-08</draft>
        <updated-by>
            <doc-id>RFC9353</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5088</errata-url>
        <doi>10.17487/RFC5088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5089</doc-id>
        <title>IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery</title>
        <author>
            <name>JL. Le Roux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ikejiri</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>path computation client</kw>
            <kw>pcc</kw>
            <kw>intermediate system to intermediate system</kw>
        </keywords>
        <abstract><p>There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.  When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding.  For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-disco-proto-isis-08</draft>
        <updated-by>
            <doc-id>RFC9353</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5089</errata-url>
        <doi>10.17487/RFC5089</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5090</doc-id>
        <title>RADIUS Extension for Digest Authentication</title>
        <author>
            <name>B. Sterman</name>
        </author>
        <author>
            <name>D. Sadolevsky</name>
        </author>
        <author>
            <name>D. Schwartz</name>
        </author>
        <author>
            <name>D. Williams</name>
        </author>
        <author>
            <name>W. Beck</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>sip</kw>
            <kw>http</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-rfc4590bis-02</draft>
        <obsoletes>
            <doc-id>RFC4590</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5090</errata-url>
        <doi>10.17487/RFC5090</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5091</doc-id>
        <title>Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems</title>
        <author>
            <name>X. Boyen</name>
        </author>
        <author>
            <name>L. Martin</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>Encryption</kw>
            <kw>Cryptography</kw>
            <kw>Security</kw>
            <kw>Elliptic Curves</kw>
            <kw>Elliptic Curve Cryptography</kw>
            <kw>Pairing-based Cryptography</kw>
            <kw>Identity-based Cryptography</kw>
            <kw>Identity-based Encryption</kw>
            <kw>Boneh-Franklin Encryption Scheme</kw>
            <kw>Boneh-Boyen Encryption Scheme</kw>
        </keywords>
        <abstract><p>This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption.  This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-martin-ibcs-07</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5091</errata-url>
        <doi>10.17487/RFC5091</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5092</doc-id>
        <title>IMAP URL Scheme</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>November</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>IMAP-URL</kw>
            <kw>remote access store</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Identifiers</kw>
        </keywords>
        <abstract><p>IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.</p><p> This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-rfc2192bis-09</draft>
        <obsoletes>
            <doc-id>RFC2192</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4467</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5593</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5092</errata-url>
        <doi>10.17487/RFC5092</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5093</doc-id>
        <title>BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)</title>
        <author>
            <name>G. Hunt</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>next-generation network</kw>
            <kw>rtcp xr</kw>
            <kw>real time control protocol</kw>
            <kw>extended reports</kw>
            <kw>transport</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract><p>This document describes an RTCP XR report block, which reports packet transport parameters.  The report block was developed by BT for pre-standards use in BT's next-generation network.  This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611.  This specification does not standardise the new report block for use outside BT's network.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hunt-avt-rtcpxnq-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5094</doc-id>
        <title>Mobile IPv6 Vendor Specific Option</title>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>A. Patel</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>mobility header</kw>
            <kw>mip6</kw>
            <kw>mipv6</kw>
        </keywords>
        <abstract><p>There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes.  This document defines a new vendor-specific mobility option. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-vsm-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC5094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5095</doc-id>
        <title>Deprecation of Type 0 Routing Headers in IPv6</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>G. Neville-Neil</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ipv6 type 0 routing header</kw>
            <kw>traffic amplification</kw>
        </keywords>
        <abstract><p>The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic.  This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-deprecate-rh0-01</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
            <doc-id>RFC4294</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC5095</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5096</doc-id>
        <title>Mobile IPv6 Experimental Messages</title>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>mip6</kw>
            <kw>mobility header</kw>
            <kw>mobility option</kw>
            <kw>mipv6</kw>
        </keywords>
        <abstract><p>This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-experimental-messages-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC5096</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5097</doc-id>
        <title>MIB for the UDP-Lite protocol</title>
        <author>
            <name>G. Renker</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SMIv2</kw>
            <kw>UDPLITE-MIB</kw>
            <kw>management information base</kw>
            <kw>lightweight user datagram protocol</kw>
        </keywords>
        <abstract><p>This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite).  It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite.  UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option.  This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-udplite-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5097</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5098</doc-id>
        <title>Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)</title>
        <author>
            <name>G. Beacham</name>
        </author>
        <author>
            <name>S. Kumar</name>
        </author>
        <author>
            <name>S. Channabasappa</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>PKTC-IETF-SIG-MIB</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>packetcable-compliant</kw>
            <kw>ipcablecom-compliant</kw>
        </keywords>
        <abstract><p>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 Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-pktc-signaling-15</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5098</errata-url>
        <doi>10.17487/RFC5098</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5099</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5100</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5101</doc-id>
        <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information</title>
        <author>
            <name>B. Claise</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>exporting process</kw>
            <kw>collecting process</kw>
            <kw>template records</kw>
        </keywords>
        <abstract><p>This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network.  In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-protocol-26</draft>
        <obsoleted-by>
            <doc-id>RFC7011</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5101</errata-url>
        <doi>10.17487/RFC5101</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5102</doc-id>
        <title>Information Model for IP Flow Information Export</title>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>J. Meyer</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>171</page-count>
        <keywords>
            <kw>ipfix</kw>
            <kw>ip flow information export protocol</kw>
            <kw>measured traffic</kw>
            <kw>observation point</kw>
            <kw>metering process</kw>
            <kw>exporting process</kw>
        </keywords>
        <abstract><p>This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-info-15</draft>
        <obsoleted-by>
            <doc-id>RFC7012</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6313</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5102</errata-url>
        <doi>10.17487/RFC5102</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5103</doc-id>
        <title>Bidirectional Flow Export Using IP Flow Information Export (IPFIX)</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>E. Boschi</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>flow record</kw>
            <kw>biflow</kw>
        </keywords>
        <abstract><p>This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-biflow-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5103</errata-url>
        <doi>10.17487/RFC5103</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5104</doc-id>
        <title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</title>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>U. Chandra</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>B. Burman</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>real time protocol</kw>
            <kw>real-time protocol</kw>
            <kw></kw>
            <kw>itu-t rec. h271</kw>
            <kw>video back channel</kw>
            <kw>full intra request</kw>
            <kw>temporary maximum media stream bit rate</kw>
            <kw>temporal-spatial trade-off</kw>
        </keywords>
        <abstract><p>This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.</p><p> The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-avpf-ccm-10</draft>
        <updated-by>
            <doc-id>RFC7728</doc-id>
            <doc-id>RFC8082</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5104</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5105</doc-id>
        <title>ENUM Validation Token Format Definition</title>
        <author>
            <name>O. Lendl</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>telephone number mapping</kw>
            <kw>e.164</kw>
        </keywords>
        <abstract><p>An ENUM domain name is tightly coupled with the underlying E.164 number.  The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation".  This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-validation-token-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5105</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5106</doc-id>
        <title>The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Kroeselberg</name>
        </author>
        <author>
            <name>A. Pashalidis</name>
        </author>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>F. Bersani</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>cryptographic ciphersuite negotiation</kw>
            <kw>hash function agility</kw>
            <kw>identity confidentiality</kw>
            <kw>fragmentation</kw>
            <kw>fast reconnect mode</kw>
        </keywords>
        <abstract><p>This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol.  EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server.  It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates.  EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-tschofenig-eap-ikev2-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5106</errata-url>
        <doi>10.17487/RFC5106</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5107</doc-id>
        <title>DHCP Server Identifier Override Suboption</title>
        <author>
            <name>R. Johnson</name>
        </author>
        <author>
            <name>J. Kumarasamy</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup langauge</kw>
            <kw>dynamic host configuration protocol</kw>
            <kw>RENEW DHCPREQUEST</kw>
            <kw>DHCP RENEW</kw>
        </keywords>
        <abstract><p>This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server.  This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly.  This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-server-override-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC5107</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5108</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5109</doc-id>
        <title>RTP Payload Format for Generic Forward Error Correction</title>
        <author>
            <name>A. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>fec</kw>
            <kw>realtime transport protocol</kw>
        </keywords>
        <abstract><p>This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP.  It is based on the exclusive-or (parity) operation.  The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics.  It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation.  This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data.  This specification obsoletes RFC 2733 and RFC 3009.  The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-ulp-23</draft>
        <obsoletes>
            <doc-id>RFC2733</doc-id>
            <doc-id>RFC3009</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5109</errata-url>
        <doi>10.17487/RFC5109</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5110</doc-id>
        <title>Overview of the Internet Multicast Routing Architecture</title>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>RFC 3913</kw>
            <kw>RFC 2189</kw>
            <kw>RFC 2201</kw>
            <kw>RFC 1584</kw>
        </keywords>
        <abstract><p>This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.</p><p> This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mboned-routingarch-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC5110</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5111</doc-id>
        <title>Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>L. Dondeti</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>working group formation</kw>
            <kw>bof</kw>
            <kw>birds of a feather</kw>
        </keywords>
        <abstract><p>This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group.  Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation.  Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-aboba-sg-experiment-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5112</doc-id>
        <title>The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>communication session</kw>
            <kw>event notification</kw>
            <kw>presence</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions.  The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events.  One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents.  SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates.  However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents.  This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency.  The dictionary is compression-algorithm independent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-garcia-simple-presence-dictionary-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5112</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5113</doc-id>
        <title>Network Discovery and Selection Problem</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Bari</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network.  This document defines the network discovery and selection problem, dividing it into multiple sub- problems.  Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-eap-netsel-problem-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>eap</wg_acronym>
        <doi>10.17487/RFC5113</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5114</doc-id>
        <title>Additional Diffie-Hellman Groups for Use with IETF Standards</title>
        <author>
            <name>M. Lepinski</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>elliptic curve</kw>
            <kw>ike</kw>
            <kw>tls</kw>
            <kw>ssh</kw>
            <kw>smime</kw>
            <kw>x.509</kw>
        </keywords>
        <abstract><p>This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE).</p><p> All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography.</p><p> These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-lepinski-dh-groups-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5114</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5115</doc-id>
        <title>Telephony Routing over IP (TRIP) Attribute for Resource Priority</title>
        <author>
            <name>K. Carlberg</name>
        </author>
        <author>
            <name>P. O'Hanlon</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ip telephony</kw>
            <kw>ResourcePriority</kw>
        </keywords>
        <abstract><p>This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol.  The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway.  Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S.  and Government Telephone Preference Scheme (GTPS) in the U.K.  The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-carlberg-trip-attribute-rp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5115</errata-url>
        <doi>10.17487/RFC5115</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5116</doc-id>
        <title>An Interface and Algorithms for Authenticated Encryption</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Encryption</kw>
            <kw>Authentication</kw>
            <kw>AEAD</kw>
            <kw>authenticated encryption with associated data</kw>
        </keywords>
        <abstract><p>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mcgrew-auth-enc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5116</errata-url>
        <doi>10.17487/RFC5116</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5117</doc-id>
        <title>RTP Topologies</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>multi-endpoint topologies</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments.  In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-avt-topologies-07</draft>
        <obsoleted-by>
            <doc-id>RFC7667</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5117</errata-url>
        <doi>10.17487/RFC5117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5118</doc-id>
        <title>Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)</title>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>C. Boulton</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Torture test</kw>
            <kw>IPv6</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-ipv6-torture-tests-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5118</errata-url>
        <doi>10.17487/RFC5118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5119</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)</title>
        <author>
            <name>T. Edwards</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>persistent resources</kw>
            <kw>universal labels,</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages.  A subnamespace for Universal Labels is specifically described.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-edwards-urn-smpte-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5119</errata-url>
        <doi>10.17487/RFC5119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5120</doc-id>
        <title>M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)</title>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>N. Sheth</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>is-is</kw>
        </keywords>
        <abstract><p>This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds.  This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs).  This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-wg-multi-topology-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5120</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5121</doc-id>
        <title>Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks</title>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>F. Xia</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>JH. Choi</name>
        </author>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Neighbor Discovery</kw>
            <kw>Per-MS Perfix</kw>
        </keywords>
        <abstract><p>IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems.  Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control).  The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet).  IPv6 packets can be sent and received via the IP-specific part of the Packet CS.  This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface.  It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-16ng-ipv6-over-ipv6cs-11</draft>
        <updated-by>
            <doc-id>RFC8064</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>16ng</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5121</errata-url>
        <doi>10.17487/RFC5121</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5122</doc-id>
        <title>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>Internationalized Resource Identifier</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>Jabber</kw>
            <kw>xmpp</kw>
            <kw>iri</kw>
            <kw>uri</kw>
        </keywords>
        <abstract><p>This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-saintandre-rfc4622bis-01</draft>
        <obsoletes>
            <doc-id>RFC4622</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5122</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5123</doc-id>
        <title>Considerations in Validating the Path in BGP</title>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>B. Akyol</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>bgp autonomous system path</kw>
            <kw>bgp as path</kw>
        </keywords>
        <abstract><p>This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-white-pathconsiderations-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5123</errata-url>
        <doi>10.17487/RFC5123</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5124</doc-id>
        <title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>E. Carrara</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>avpf</kw>
            <kw>rtp communication</kw>
        </keywords>
        <abstract><p>An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively.  This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-profile-savpf-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5124</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5125</doc-id>
        <title>Reclassification of RFC 3525 to Historic</title>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>MEGACO</kw>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract><p>This document reclassifies RFC 3525, Gateway Control Protocol Version 1, to Historic Status.  This memo also obsoletes RFC 3525.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-taylor-megaco-obsol3525-01</draft>
        <obsoletes>
            <doc-id>RFC3525</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5125</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5126</doc-id>
        <title>CMS Advanced Electronic Signatures (CAdES)</title>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>N. Pope</name>
        </author>
        <author>
            <name>J. Ross</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>141</page-count>
        <keywords>
            <kw>verifying party</kw>
            <kw>signer</kw>
            <kw>purchase</kw>
            <kw>contract</kw>
            <kw>invoice</kw>
            <kw>application</kw>
            <kw>smart cards</kw>
            <kw>data</kw>
        </keywords>
        <abstract><p>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.</p><p> The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined.</p><p> The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it.</p><p> The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-smime-cades-07</draft>
        <obsoletes>
            <doc-id>RFC3126</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC5126</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5127</doc-id>
        <title>Aggregation of Diffserv Service Classes</title>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>J. Babiarz</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Treatment Aggregate</kw>
            <kw>forwarding treatment</kw>
        </keywords>
        <abstract><p>In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network.  Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications.  However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes.  In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment.  This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tsvwg-diffserv-class-aggr-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5128</doc-id>
        <title>State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>B. Ford</name>
        </author>
        <author>
            <name>D. Kegel</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time.  Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described.  This memo covers NAT traversal approaches used by both TCP- and UDP-based applications.  This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-behave-p2p-state-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5128</errata-url>
        <doi>10.17487/RFC5128</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5129</doc-id>
        <title>Explicit Congestion Marking in MPLS</title>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <author>
            <name>J. Tay</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Diffserv</kw>
            <kw>Differentiated Services</kw>
            <kw>QOS</kw>
            <kw>ECN tunnel</kw>
        </keywords>
        <abstract><p>RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header.  DSCPs may be encoded in the EXP field, while other uses of that field are not precluded.  RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header.  This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-mpls-02</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5462</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5129</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5130</doc-id>
        <title>A Policy Control Mechanism in IS-IS Using Administrative Tags</title>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Shand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Martin</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>intermediate systetm to intermediate system</kw>
            <kw>ip prefix distribution</kw>
            <kw>lsp</kw>
            <kw>link state protocol</kw>
        </keywords>
        <abstract><p>This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain.  This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use.  This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-admin-tags-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5131</doc-id>
        <title>A MIB Textual Convention for Language Tags</title>
        <author>
            <name>D. McWalter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>LANGTAG-TC-MIB</kw>
        </keywords>
        <abstract><p>This MIB module defines a textual convention to represent BCP 47 language tags.  The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mcwalter-langtag-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5131</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5132</doc-id>
        <title>IP Multicast MIB</title>
        <author>
            <name>D. McWalter</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>A. Kessler</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>managament information base</kw>
            <kw>IPMCAST-MIB,</kw>
        </keywords>
        <abstract><p>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 multicast function, independent of the specific multicast protocol(s) in use.  This document obsoletes RFC 2932. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mboned-ip-mcast-mib-07</draft>
        <obsoletes>
            <doc-id>RFC2932</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC5132</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5133</doc-id>
        <title>Terminal Endpoint Identifier (TEI) Query Request Number Change</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>K. Morneault</name>
        </author>
        <date>
            <month>December</month>
            <year>2007</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>isdn q.921-user adaptation layer</kw>
            <kw>iua</kw>
        </keywords>
        <abstract><p>The Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5.  However, this number is already being used by the Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.  This document updates RFC 4233 such that the message type of TEI Query Request messages is 8. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sigtran-rfc4233update-02</draft>
        <updates>
            <doc-id>RFC4233</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sigtran</wg_acronym>
        <doi>10.17487/RFC5133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5134</doc-id>
        <title>A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>uniform resource name</kw>
            <kw>Auto-ID</kw>
            <kw>RFID</kw>
            <kw>EPCglobal</kw>
            <kw>EPC</kw>
            <kw>UPC</kw>
            <kw>supply chain management</kw>
            <kw>bar code</kw>
        </keywords>
        <abstract><p>This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mealling-epc-urn-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5134</errata-url>
        <doi>10.17487/RFC5134</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5135</doc-id>
        <title>IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)</title>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>multicast application</kw>
            <kw>multicast nat</kw>
        </keywords>
        <abstract><p>This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast.  An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-behave-multicast-12</draft>
        <is-also>
            <doc-id>BCP0135</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5135</errata-url>
        <doi>10.17487/RFC5135</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5136</doc-id>
        <title>Defining Network Capacity</title>
        <author>
            <name>P. Chimento</name>
        </author>
        <author>
            <name>J. Ishac</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>bandwidth</kw>
            <kw>bandwidth estimation</kw>
            <kw>capacity estimation</kw>
            <kw>link capacity</kw>
            <kw>available capacity</kw>
            <kw>narrow link</kw>
            <kw>tight link</kw>
        </keywords>
        <abstract><p>Measuring capacity is a task that sounds simple, but in reality can be quite complex.  In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs.  This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network.  By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ippm-bw-capacity-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC5136</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5137</doc-id>
        <title>ASCII Escaping of Unicode Characters</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Text</kw>
            <kw>internationalization</kw>
            <kw>ascii</kw>
            <kw>unicode</kw>
            <kw>utf-8</kw>
            <kw>encoding</kw>
        </keywords>
        <abstract><p>There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly.  With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways.  The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes.  This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-klensin-unicode-escapes-07</draft>
        <is-also>
            <doc-id>BCP0137</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5137</errata-url>
        <doi>10.17487/RFC5137</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5138</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI)</title>
        <author>
            <name>S. Cox</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application of Geoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI.  The formal Namespace Identifier (NID) is "cgi".  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-sjdcox-cgi-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5138</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5139</doc-id>
        <title>Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>location</kw>
            <kw>civic location</kw>
            <kw>pidf-lo</kw>
            <kw>civic address</kw>
        </keywords>
        <abstract><p>This document defines an XML format for the representation of civic location.  This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119.  The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes.  The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-revised-civic-lo-07</draft>
        <updates>
            <doc-id>RFC4119</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC5139</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5140</doc-id>
        <title>A Telephony Gateway REgistration Protocol (TGREP)</title>
        <author>
            <name>M. Bangalore</name>
        </author>
        <author>
            <name>R. Kumar</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Salama</name>
        </author>
        <author>
            <name>D.N. Shah</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>telephony prefix</kw>
            <kw>soft switches</kw>
            <kw>telephony routing over ip</kw>
            <kw>trip</kw>
            <kw>internet telephony administrative domains</kw>
            <kw>itad</kw>
        </keywords>
        <abstract><p>This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches.  The registration mechanism can also be used to export resource information.  The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs).  TGREP shares a lot of similarities with the TRIP protocol.  It has similar procedures and finite state machine for session establishment.  It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-iptel-tgrep-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5140</errata-url>
        <doi>10.17487/RFC5140</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5141</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)</title>
        <author>
            <name>J. Goodwin</name>
        </author>
        <author>
            <name>H. Apel</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>urn nid</kw>
            <kw>uniform resource name namespace identification</kw>
            <kw>NSS</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO).  This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-goodwin-iso-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5141</errata-url>
        <doi>10.17487/RFC5141</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5142</doc-id>
        <title>Mobility Header Home Agent Switch Message</title>
        <author>
            <name>B. Haley</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-ha-switch-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC5142</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5143</doc-id>
        <title>Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>J. Brayley</name>
        </author>
        <author>
            <name>J. Shirron</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>S. Vogelsang</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>psn</kw>
            <kw>packet switched network</kw>
            <kw>RFC4842</kw>
        </keywords>
        <abstract><p>This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs).  The PSNs explicitly supported by this document include MPLS and IP.  Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired.  This memo defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-malis-sonet-ces-mpls-09</draft>
        <obsoleted-by>
            <doc-id>RFC4842</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5143</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5144</doc-id>
        <title>A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>M. Sanz</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>dreg</kw>
            <kw>iris domain registry</kw>
        </keywords>
        <abstract><p>This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-crisp-iris-dchk-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>crisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5144</errata-url>
        <doi>10.17487/RFC5144</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5145</doc-id>
        <title>Framework for MPLS-TE to GMPLS Migration</title>
        <author>
            <name>K. Shiomoto</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>multiprotocol label switching traffic engineering</kw>
            <kw>control plane</kw>
        </keywords>
        <abstract><p>The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.</p><p> This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.</p><p> This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5145</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5146</doc-id>
        <title>Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks</title>
        <author>
            <name>K. Kumaki</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>multiprotocol label switching traffic engineering</kw>
            <kw>service provider requirements</kw>
        </keywords>
        <abstract><p>Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).</p><p> The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.</p><p> This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5146</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5147</doc-id>
        <title>URI Fragment Identifiers for the text/plain Media Type</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <author>
            <name>M. Duerst</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>mime entity</kw>
        </keywords>
        <abstract><p>This memo defines URI fragment identifiers for text/plain MIME entities.  These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range.  Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-wilde-text-fragment-09</draft>
        <updates>
            <doc-id>RFC2046</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5147</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5148</doc-id>
        <title>Jitter Considerations in Mobile Ad Hoc Networks (MANETs)</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>B. Adamson</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>randomly modifying timing</kw>
            <kw>control traffic transmission</kw>
            <kw>tranmission collision</kw>
        </keywords>
        <abstract><p>This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-manet-jitter-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5148</errata-url>
        <doi>10.17487/RFC5148</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5149</doc-id>
        <title>Service Selection for Mobile IPv6</title>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>U. Nilsson</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>mipv6</kw>
            <kw>service selection mobility option</kw>
            <kw>proxy mobile ipv6</kw>
            <kw>mobilty service subscription</kw>
            <kw>binding registration procedure</kw>
        </keywords>
        <abstract><p>In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription.  A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription.  This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-korhonen-mip6-service-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5149</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5150</doc-id>
        <title>Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)</title>
        <author>
            <name>A. Ayyangar</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>lsp</kw>
            <kw>label switched paths</kw>
            <kw>e2e lsp</kw>
            <kw>lsp stitching</kw>
            <kw>lsp segments</kw>
            <kw>s-lsp</kw>
        </keywords>
        <abstract><p>In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).</p><p> This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.</p><p> It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lsp-stitching-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5150</errata-url>
        <doi>10.17487/RFC5150</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5151</doc-id>
        <title>Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Ayyangar</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpls-te</kw>
        </keywords>
        <abstract><p>This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.</p><p> For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-inter-domain-rsvp-te-07</draft>
        <updates>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5151</errata-url>
        <doi>10.17487/RFC5151</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5152</doc-id>
        <title>A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Ayyangar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>gmpls</kw>
        </keywords>
        <abstract><p>This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.</p><p> Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-inter-domain-pd-path-comp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5152</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5153</doc-id>
        <title>IP Flow Information Export (IPFIX) Implementation Guidelines</title>
        <author>
            <name>E. Boschi</name>
        </author>
        <author>
            <name>L. Mark</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>template mangaement</kw>
            <kw>exporting processes</kw>
            <kw>collecting processes</kw>
            <kw>ipfix middleboxes</kw>
        </keywords>
        <abstract><p>The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices.  This document provides guidelines for the implementation and use of the IPFIX protocol.  Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipfix-implementation-guidelines-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5153</errata-url>
        <doi>10.17487/RFC5153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5154</doc-id>
        <title>IP over IEEE 802.16 Problem Statement and Goals</title>
        <author>
            <name>J. Jee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <author>
            <name>J. Mandin</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>WiMAX</kw>
            <kw>Mobile WiMAX</kw>
            <kw>WiBro</kw>
        </keywords>
        <abstract><p>This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support.  This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers.  Common terminology used for the base guideline while defining the solution framework is also presented.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-16ng-ps-goals-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>16ng</wg_acronym>
        <doi>10.17487/RFC5154</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5155</doc-id>
        <title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
        <author>
            <name>B. Laurie</name>
        </author>
        <author>
            <name>G. Sisson</name>
        </author>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>D. Blacka</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>nsec</kw>
            <kw>resource record</kw>
            <kw>nsec3</kw>
        </keywords>
        <abstract><p>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence.  This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence.  However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-nsec3-13</draft>
        <updated-by>
            <doc-id>RFC6840</doc-id>
            <doc-id>RFC6944</doc-id>
            <doc-id>RFC9077</doc-id>
            <doc-id>RFC9157</doc-id>
            <doc-id>RFC9276</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5155</errata-url>
        <doi>10.17487/RFC5155</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5156</doc-id>
        <title>Special-Use IPv6 Addresses</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>invalid routing prefix</kw>
        </keywords>
        <abstract><p>This document is a compilation of special IPv6 addresses defined in other RFCs.  It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets.  It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-rfc3330-for-ipv6-04</draft>
        <obsoleted-by>
            <doc-id>RFC6890</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC5156</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5157</doc-id>
        <title>IPv6 Implications for Network Scanning</title>
        <author>
            <name>T. Chown</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>subnet address space</kw>
        </keywords>
        <abstract><p>The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective.  While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them.  This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-scanning-implications-04</draft>
        <obsoleted-by>
            <doc-id>RFC7707</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC5157</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5158</doc-id>
        <title>6to4 Reverse DNS Delegation Specification</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file.  The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain.  In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-huston-6to4-reverse-dns-07</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5158</errata-url>
        <doi>10.17487/RFC5158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5159</doc-id>
        <title>Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection</title>
        <author>
            <name>L. Dondeti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Jerichow</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>IANA registration</kw>
            <kw>OMA BCAST</kw>
        </keywords>
        <abstract><p>This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dondeti-oma-mmusic-sdp-attrs-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5160</doc-id>
        <title>Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)</title>
        <author>
            <name>P. Levis</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>sls</kw>
            <kw>bgp</kw>
            <kw>peering</kw>
            <kw>diffserv</kw>
            <kw>parallel internet</kw>
        </keywords>
        <abstract><p>This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet.  It defines terminology relevant to inter-domain QoS models.  It proposes a new concept denoted by Meta-QoS-Class (MQC).  This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers.  It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-levis-provider-qos-agreement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5160</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5161</doc-id>
        <title>The IMAP ENABLE Extension</title>
        <author>
            <name>A. Gulbrandsen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Internet Message Access Protocol</kw>
        </keywords>
        <abstract><p>Most IMAP extensions are used by the client when it wants to and the server supports it.  However, a few extensions require the server to know whether a client supports that extension.  The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gulbrandsen-imap-enable-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5162</doc-id>
        <title>IMAP4 Extensions for Quick Mailbox Resynchronization</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>D. Cridland</name>
        </author>
        <author>
            <name>C. Wilson</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Internet Message Access Protocol</kw>
        </keywords>
        <abstract><p>This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips.  This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-reconnect-client-06</draft>
        <obsoleted-by>
            <doc-id>RFC7162</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5162</errata-url>
        <doi>10.17487/RFC5162</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5163</doc-id>
        <title>Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>B. Collini-Nocker</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>digital video broadcasting</kw>
            <kw>dvb</kw>
            <kw>mpeg-2 ts-concat</kw>
            <kw>pdu-concat</kw>
            <kw>timestamp</kw>
        </keywords>
        <abstract><p>This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.</p><p> The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipdvb-ule-ext-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipdvb</wg_acronym>
        <doi>10.17487/RFC5163</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5164</doc-id>
        <title>Mobility Services Transport: Problem Statement</title>
        <author>
            <name>T. Melia</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>intelligent access selection</kw>
            <kw>ip handover mechanism</kw>
        </keywords>
        <abstract><p>There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21.  Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa.  The protocol requirements for this signalling have both transport and security issues that must be considered.  The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF.  This document presents a problem statement for this core problem.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-mis-ps-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5164</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5165</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC)</title>
        <author>
            <name>C. Reed</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>location</kw>
            <kw>geospatial</kw>
            <kw>namespace</kw>
            <kw>OGC</kw>
            <kw>URN</kw>
            <kw>Open Geospatial Consortium</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC.  The formal Namespace IDentifier (NID) is "ogc".  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-creed-ogc-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5165</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5166</doc-id>
        <title>Metrics for the Evaluation of Congestion Control Mechanisms</title>
        <author>
            <name>S. Floyd</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>transport protocol</kw>
            <kw>transport modeling research group</kw>
            <kw>tmrg</kw>
        </keywords>
        <abstract><p>This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.</p><p> This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-tmrg-metrics-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5166</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5167</doc-id>
        <title>Media Server Control Protocol Requirements</title>
        <author>
            <name>M. Dolly</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>logical entities</kw>
            <kw>mcp</kw>
            <kw>interactive voice response</kw>
            <kw>conferencing media services</kw>
        </keywords>
        <abstract><p>This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.</p><p> This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mediactrl-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <doi>10.17487/RFC5167</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5168</doc-id>
        <title>XML Schema for Media Control</title>
        <author>
            <name>O. Levin</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>P. Hagendorf</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>video fast update</kw>
        </keywords>
        <abstract><p>This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors.  This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner.  New implementations are discouraged from using the method described except for backward compatibility purposes.  New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-levin-mmusic-xml-media-control-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5169</doc-id>
        <title>Handover Key Management and Re-Authentication Problem Statement</title>
        <author>
            <name>T. Clancy</name>
        </author>
        <author>
            <name>M. Nakhjiri</name>
        </author>
        <author>
            <name>V. Narayanan</name>
        </author>
        <author>
            <name>L. Dondeti</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>hokey</kw>
            <kw>handover key management</kw>
            <kw>fast re-authentication</kw>
            <kw>mobility</kw>
        </keywords>
        <abstract><p>This document describes the Handover Keying (HOKEY) re-authentication problem statement.  The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method.  This often causes unacceptable latency in various mobile wireless environments.  This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-hokey-reauth-ps-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5169</errata-url>
        <doi>10.17487/RFC5169</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5170</doc-id>
        <title>Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>C. Neumann</name>
        </author>
        <author>
            <name>D. Furodet</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>LDPC</kw>
            <kw>FEC</kw>
        </keywords>
        <abstract><p>This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission).  These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-ldpc-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC5170</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5171</doc-id>
        <title>Cisco Systems UniDirectional Link Detection (UDLD) Protocol</title>
        <author>
            <name>M. Foschiano</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Ethernet</kw>
            <kw>switches</kw>
            <kw>LAN</kw>
            <kw>IEEE</kw>
            <kw>802</kw>
            <kw>spanning tree</kw>
            <kw>STP</kw>
            <kw>FEFI</kw>
            <kw>autonegotiation</kw>
        </keywords>
        <abstract><p>This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.</p><p> This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-foschiano-udld-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5171</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5172</doc-id>
        <title>Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol</title>
        <author>
            <name>S. Varada</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>The Point-to-Point Protocol (PPP) 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.</p><p> The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.</p><p> This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipv6-compression-nego-v2-02</draft>
        <obsoletes>
            <doc-id>RFC2472</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC5172</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5173</doc-id>
        <title>Sieve Email Filtering: Body Extension</title>
        <author>
            <name>J. Degener</name>
        </author>
        <author>
            <name>P. Guenther</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>search</kw>
            <kw>full text</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-body-09</draft>
        <updates>
            <doc-id>RFC5229</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5173</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5174</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU)</title>
        <author>
            <name>J-P. Evain</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>EBU</kw>
            <kw>namespace</kw>
            <kw>urn</kw>
            <kw>broadcast</kw>
            <kw>metadata</kw>
            <kw>classification</kw>
            <kw>schema</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources.  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 the EBU.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-evain-ebu-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5174</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5175</doc-id>
        <title>IPv6 Router Advertisement Flags Option</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>neighbor discovery protocol</kw>
            <kw>ndp</kw>
            <kw>expanded flags option</kw>
            <kw>efo</kw>
            <kw>ndp  router advertisement message</kw>
        </keywords>
        <abstract><p>The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags.  Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field.  This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK]</p></abstract>
        <obsoletes>
            <doc-id>RFC5075</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipv6</wg_acronym>
        <doi>10.17487/RFC5175</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5176</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>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>user session</kw>
        </keywords>
        <abstract><p>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.</p></abstract>
        <draft>draft-ietf-radext-rfc3576bis-13</draft>
        <obsoletes>
            <doc-id>RFC3576</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8559</doc-id>
            <doc-id>RFC9765</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5176</errata-url>
        <doi>10.17487/RFC5176</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5177</doc-id>
        <title>Network Mobility (NEMO) Extensions for Mobile IPv4</title>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>V. Narayanan</name>
        </author>
        <author>
            <name>A. Petrescu</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>NEMOv4</kw>
            <kw>Mobile Networks</kw>
            <kw>Moving Networks</kw>
            <kw>Mobile Router</kw>
            <kw>Local Fixed Node</kw>
            <kw>Prefix Table</kw>
            <kw>Mobile Network Prefix</kw>
            <kw>Nested Mobile Networks</kw>
            <kw>Nested Network Mobility</kw>
        </keywords>
        <abstract><p>This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.</p><p> Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-nemo-v4-base-11</draft>
        <updated-by>
            <doc-id>RFC6626</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC5177</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5178</doc-id>
        <title>Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type</title>
        <author>
            <name>N. Williams</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>domain-based-name</kw>
            <kw>gss-domain-based-services</kw>
            <kw>GSS_C_NT_DOMAINBASED_SERVICE</kw>
        </keywords>
        <abstract><p>This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.</p><p> Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-gssapi-domain-based-names-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC5178</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5179</doc-id>
        <title>Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>domain-name-based</kw>
            <kw>GSS_C_NT_DOMAINBASED_SERVICE</kw>
        </keywords>
        <abstract><p>This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-krb5-gssapi-domain-based-names-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC5179</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5180</doc-id>
        <title>IPv6 Benchmarking Methodology for Network Interconnect Devices</title>
        <author>
            <name>C. Popoviciu</name>
        </author>
        <author>
            <name>A. Hamza</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>D. Dugatkin</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>rfc2544</kw>
            <kw>ipv6</kw>
            <kw>benchmarking guidelines</kw>
        </keywords>
        <abstract><p>The benchmarking methodologies defined in RFC 2544 are IP version independent.  However, RFC 2544 does not address some of the specificities of IPv6.  This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices.  IPv6 transition mechanisms are outside the scope of this document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-ipv6-meth-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5180</errata-url>
        <doi>10.17487/RFC5180</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5181</doc-id>
        <title>IPv6 Deployment Scenarios in 802.16 Networks</title>
        <author>
            <name>M-K. Shin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y-H. Han</name>
        </author>
        <author>
            <name>S-E. Kim</name>
        </author>
        <author>
            <name>D. Premec</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Ethernet CS (Convergence Sublayer)</kw>
            <kw>IPv6 CS (Convergence Sublayer)</kw>
        </keywords>
        <abstract><p>This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services.  In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-802-16-deployment-scenarios-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC5181</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5182</doc-id>
        <title>IMAP Extension for Referencing the Last SEARCH Result</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>uid</kw>
            <kw>unique identifier</kw>
            <kw>searchres</kw>
            <kw>internet message access protocol</kw>
        </keywords>
        <abstract><p>Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.</p><p> This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.</p><p> This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-imap-search-res-07</draft>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5182</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5183</doc-id>
        <title>Sieve Email Filtering: Environment Extension</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>vnd</kw>
        </keywords>
        <abstract><p>This document describes the "environment" extension to the Sieve email filtering language.  The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-freed-sieve-environment-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5183</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5184</doc-id>
        <title>Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover</title>
        <author>
            <name>F. Teraoka</name>
        </author>
        <author>
            <name>K. Gogo</name>
        </author>
        <author>
            <name>K. Mitsuya</name>
        </author>
        <author>
            <name>R. Shibui</name>
        </author>
        <author>
            <name>K. Mitani</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>l2 triggers</kw>
            <kw>primitives</kw>
            <kw>l3-driven fast handover</kw>
            <kw>ip mobility optimizations</kw>
            <kw>mobopts</kw>
        </keywords>
        <abstract><p>This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers.  For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers.  However, each protocol layer is basically designed independently.  Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers.  This document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem.  This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-mobopts-l2-abstractions-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5184</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5185</doc-id>
        <title>OSPF Multi-Area Adjacency</title>
        <author>
            <name>S. Mirtorabi</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Oswal</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>inter-area</kw>
            <kw>intra-area path</kw>
        </keywords>
        <abstract><p>This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas.  This is necessary to allow the link to be considered an intra-area link in multiple areas.  This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-multi-area-adj-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5185</errata-url>
        <doi>10.17487/RFC5185</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5186</doc-id>
        <title>Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>J. Martin</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>source information</kw>
            <kw>source-filtering group management</kw>
        </keywords>
        <abstract><p>The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols.  The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information.  This document describes how multicast routing protocols will interact with these source-filtering group management protocols.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-magma-igmpv3-and-routing-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <doi>10.17487/RFC5186</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5187</doc-id>
        <title>OSPFv3 Graceful Restart</title>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This document describes the OSPFv3 graceful restart.  The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document.  These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-graceful-restart-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5187</errata-url>
        <doi>10.17487/RFC5187</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5188</doc-id>
        <title>RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec</title>
        <author>
            <name>H. Desineni</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec.  Several media type registrations are included for EVRC-WB RTP payload formats.  In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-evrc-wb-09</draft>
        <updates>
            <doc-id>RFC4788</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5188</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5189</doc-id>
        <title>Middlebox Communication (MIDCOM) Protocol Semantics</title>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>nat</kw>
            <kw>network address translator</kw>
            <kw>firewall</kw>
        </keywords>
        <abstract><p>This document 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 document obsoletes RFC 3989. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-midcom-rfc3989-bis-02</draft>
        <obsoletes>
            <doc-id>RFC3989</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <doi>10.17487/RFC5189</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5190</doc-id>
        <title>Definitions of Managed Objects for Middlebox Communication</title>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>midcom</kw>
            <kw>MIDCOM-MIB</kw>
        </keywords>
        <abstract><p>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 configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices.  The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-midcom-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>midcom</wg_acronym>
        <doi>10.17487/RFC5190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5191</doc-id>
        <title>Protocol for Carrying Authentication for Network Access (PANA)</title>
        <author>
            <name>D. Forsberg</name>
        </author>
        <author>
            <name>Y. Ohba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>eap</kw>
            <kw>exensible authentication protocol</kw>
        </keywords>
        <abstract><p>This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks.  In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pana-pana-18</draft>
        <updated-by>
            <doc-id>RFC5872</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pana</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5191</errata-url>
        <doi>10.17487/RFC5191</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5192</doc-id>
        <title>DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents</title>
        <author>
            <name>L. Morand</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <author>
            <name>S. Kumar</name>
        </author>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
            <kw>pac</kw>
            <kw>pana client</kw>
        </keywords>
        <abstract><p>This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs).  This is one of the methods that a PANA Client (PaC) can use to locate PAAs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-paa-option-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC5192</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5193</doc-id>
        <title>Protocol for Carrying Authentication for Network Access (PANA) Framework</title>
        <author>
            <name>P. Jayaraman</name>
        </author>
        <author>
            <name>R. Lopez</name>
        </author>
        <author>
            <name>Y. Ohba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Parthasarathy</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pana-framework-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pana</wg_acronym>
        <doi>10.17487/RFC5193</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5194</doc-id>
        <title>Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)</title>
        <author>
            <name>A. van Wijk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Gybels</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>text telephone</kw>
            <kw>textphone</kw>
            <kw>deaf</kw>
            <kw>hard-of-hearing</kw>
            <kw>speech-impaired</kw>
            <kw>interactive text</kw>
            <kw>transcoding</kw>
            <kw>speech-to-text</kw>
            <kw>user alerting</kw>
            <kw>emergency services</kw>
            <kw>gateway</kw>
            <kw>analog terminal adapters</kw>
            <kw>PSTN interworking</kw>
            <kw>text presentation</kw>
            <kw>user alerting</kw>
            <kw>instant messaging</kw>
            <kw>conversation</kw>
            <kw>conversational text</kw>
            <kw>interactivity</kw>
            <kw>total conversation</kw>
            <kw>user requirements</kw>
            <kw>text gateway</kw>
            <kw>relay</kw>
            <kw>relay service</kw>
            <kw>text relay</kw>
            <kw>TTY</kw>
            <kw>text transport</kw>
            <kw>text interworking</kw>
            <kw>combination gateway</kw>
        </keywords>
        <abstract><p>This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP).  This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-toip-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5194</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5195</doc-id>
        <title>BGP-Based Auto-Discovery for Layer-1 VPNs</title>
        <author>
            <name>H. Ould-Brahim</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>import route target</kw>
            <kw>l1vpn</kw>
            <kw>single-end provisioning</kw>
        </keywords>
        <abstract><p>The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs).  The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN.  That information is necessary for completing the signaling phase of L1VPN connections.  One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l1vpn-bgp-auto-discovery-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l1vpn</wg_acronym>
        <doi>10.17487/RFC5195</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5196</doc-id>
        <title>Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)</title>
        <author>
            <name>M. Lonnfors</name>
        </author>
        <author>
            <name>K. Kiss</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>common presence data format</kw>
            <kw>cpp</kw>
            <kw>common profile for presence</kw>
        </keywords>
        <abstract><p>Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols.  This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-prescaps-ext-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC5196</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5197</doc-id>
        <title>On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions</title>
        <author>
            <name>S. Fries</name>
        </author>
        <author>
            <name>D. Ignjatic</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>key management</kw>
            <kw>media stream security</kw>
            <kw>end-to-end</kw>
            <kw>SRTP</kw>
        </keywords>
        <abstract><p>Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for \%real-time applications. In particular, it has been defined focusing on the support of the Secure \%Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.</p><p> This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-msec-mikey-applicability-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC5197</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5198</doc-id>
        <title>Unicode Format for Network Interchange</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>M. Padlipsky</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>internationalized</kw>
            <kw>utf-8</kw>
        </keywords>
        <abstract><p>The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET.  This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-klensin-net-utf8-09</draft>
        <obsoletes>
            <doc-id>RFC0698</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0854</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5198</errata-url>
        <doi>10.17487/RFC5198</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5199</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5200</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5201</doc-id>
        <title>Host Identity Protocol</title>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>P. Jokela</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>104</page-count>
        <keywords>
            <kw>hip</kw>
            <kw>ip-layer state</kw>
            <kw>integrity protection</kw>
            <kw>optional encryption</kw>
        </keywords>
        <abstract><p>This memo specifies the details of the Host Identity Protocol (HIP).  HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes.  HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication.  The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks.  When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-base-10</draft>
        <obsoleted-by>
            <doc-id>RFC7401</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6253</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5201</errata-url>
        <doi>10.17487/RFC5201</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5202</doc-id>
        <title>Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)</title>
        <author>
            <name>P. Jokela</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>P. Nikander</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>user data packets</kw>
        </keywords>
        <abstract><p>This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-esp-06</draft>
        <obsoleted-by>
            <doc-id>RFC7402</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5202</errata-url>
        <doi>10.17487/RFC5202</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5203</doc-id>
        <title>Host Identity Protocol (HIP) Registration Extension</title>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>T. Koponen</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>register</kw>
        </keywords>
        <abstract><p>This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-registration-02</draft>
        <obsoleted-by>
            <doc-id>RFC8003</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC5203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5204</doc-id>
        <title>Host Identity Protocol (HIP) Rendezvous Extension</title>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>hip registration extension</kw>
            <kw>hip nodes</kw>
            <kw>hip redezvous server</kw>
        </keywords>
        <abstract><p>This document defines a rendezvous extension for the Host Identity Protocol (HIP).  The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers.  Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-rvs-05</draft>
        <obsoleted-by>
            <doc-id>RFC8004</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC5204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5205</doc-id>
        <title>Host Identity Protocol (HIP) Domain Name System (DNS) Extensions</title>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>J. Laganier</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>hip</kw>
            <kw>host identity protocol</kw>
            <kw>host identity payload</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP).  This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-dns-09</draft>
        <obsoleted-by>
            <doc-id>RFC8005</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC5205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5206</doc-id>
        <title>End-Host Mobility and Multihoming with the Host Identity Protocol</title>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>T. Henderson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Vogt</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>hip</kw>
            <kw>multihoming extensions</kw>
            <kw>mobility extentions</kw>
            <kw>locator</kw>
        </keywords>
        <abstract><p>This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP).  Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached.  This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets.  While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-mm-05</draft>
        <obsoleted-by>
            <doc-id>RFC8046</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC5206</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5207</doc-id>
        <title>NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication</title>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>host identity protocol</kw>
            <kw>host identity payload</kw>
            <kw>NAT traversal</kw>
            <kw>middlebox traversal</kw>
            <kw>firewall traversal</kw>
            <kw>ID locator split</kw>
            <kw>problem statement</kw>
        </keywords>
        <abstract><p>The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate.  One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers.  In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet.  These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts.  Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible.  This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls.  It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes.  This document is a product of the IRTF HIP Research Group.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-hiprg-nat-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5208</doc-id>
        <title>Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>rsa laboratories</kw>
            <kw>private-key syntax</kw>
            <kw>change control</kw>
        </keywords>
        <abstract><p>This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.</p><p> This document describes a syntax for private-key information. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kaliski-pkcs8-00</draft>
        <obsoleted-by>
            <doc-id>RFC5958</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5208</errata-url>
        <doi>10.17487/RFC5208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5209</doc-id>
        <title>Network Endpoint Assessment (NEA): Overview and Requirements</title>
        <author>
            <name>P. Sangster</name>
        </author>
        <author>
            <name>H. Khosravi</name>
        </author>
        <author>
            <name>M. Mani</name>
        </author>
        <author>
            <name>K. Narayan</name>
        </author>
        <author>
            <name>J. Tardo</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>Posture</kw>
            <kw>Remediation</kw>
            <kw>reassessment</kw>
            <kw>Validator</kw>
            <kw>Collector</kw>
            <kw>Broker</kw>
            <kw>compliance</kw>
            <kw>privacy</kw>
            <kw>disclosure</kw>
            <kw>replay</kw>
            <kw>trust</kw>
            <kw>policy</kw>
        </keywords>
        <abstract><p>This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model.  NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system.  This may take place during the request for network access and/or subsequently at any time while connected to the network.  The learned posture information can then be applied to a variety of compliance-oriented decisions.  The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software.  In order to provide context for the requirements, a reference model and terminology are introduced.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nea-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>nea</wg_acronym>
        <doi>10.17487/RFC5209</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5210</doc-id>
        <title>A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience</title>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>J. Bi</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>G. Ren</name>
        </author>
        <author>
            <name>K. Xu</name>
        </author>
        <author>
            <name>M. Williams</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Source Address Validation</kw>
            <kw>Source Addressing Spoofing</kw>
            <kw>Network Security</kw>
            <kw>Testbed</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses.  In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network.  This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-wu-sava-testbed-experience-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5210</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5211</doc-id>
        <title>An Internet Transition Plan</title>
        <author>
            <name>J. Curran</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-jcurran-v6transitionplan-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5211</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5212</doc-id>
        <title>Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)</title>
        <author>
            <name>K. Shiomoto</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <author>
            <name>M. Vigoureux</name>
        </author>
        <author>
            <name>D. Brungard</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>generalized mpls</kw>
            <kw>switching technology</kw>
        </keywords>
        <abstract><p>Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.</p><p> In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-mln-reqs-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5212</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5213</doc-id>
        <title>Proxy Mobile IPv6</title>
        <author>
            <name>S. Gundavelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>mobility management</kw>
        </keywords>
        <abstract><p>Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling.  The network is responsible for managing IP mobility on behalf of the host.  The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf.  This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netlmm-proxymip6-18</draft>
        <updated-by>
            <doc-id>RFC6543</doc-id>
            <doc-id>RFC7864</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5213</errata-url>
        <doi>10.17487/RFC5213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5214</doc-id>
        <title>Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)</title>
        <author>
            <name>F. Templin</name>
        </author>
        <author>
            <name>T. Gleeson</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>ipv4</kw>
            <kw>non-broadcast multiple access</kw>
            <kw>nbma</kw>
            <kw>dual-stack</kw>
        </keywords>
        <abstract><p>The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks.  ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-templin-rfc4214bis-05</draft>
        <obsoletes>
            <doc-id>RFC4214</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5214</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5215</doc-id>
        <title>RTP Payload Format for Vorbis Encoded Audio</title>
        <author>
            <name>L. Barbato</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>realtime transport protocol</kw>
            <kw>codebook</kw>
        </keywords>
        <abstract><p>This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.</p><p> Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-vorbis-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5215</errata-url>
        <doi>10.17487/RFC5215</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5216</doc-id>
        <title>The EAP-TLS Authentication Protocol</title>
        <author>
            <name>D. Simon</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>R. Hurst</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>extensible authentication protocol</kw>
            <kw>point-to-point</kw>
            <kw>link control compression</kw>
            <kw>extensible</kw>
            <kw>transport level security</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.</p><p> This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-simon-emu-rfc2716bis-13</draft>
        <obsoletes>
            <doc-id>RFC2716</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9190</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5216</errata-url>
        <doi>10.17487/RFC5216</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5217</doc-id>
        <title>Memorandum for Multi-Domain Public Key Infrastructure Interoperability</title>
        <author>
            <name>M. Shimaoka</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Hastings</name>
        </author>
        <author>
            <name>R. Nielsen</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>pki</kw>
            <kw>multi-domain pki</kw>
            <kw>pki domain</kw>
        </keywords>
        <abstract><p>The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy.  This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shimaoka-multidomain-pki-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5217</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5218</doc-id>
        <title>What Makes for a Successful Protocol?</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success.  Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success.  It is hoped that these observations can serve as guidance for future protocol work.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-protocol-success-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5218</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5219</doc-id>
        <title>A More Loss-Tolerant RTP Payload Format for MP3 Audio</title>
        <author>
            <name>R. Finlayson</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>real time protocol</kw>
            <kw>real-time protocol</kw>
            <kw>mpeg</kw>
            <kw>moving picture experts group,</kw>
        </keywords>
        <abstract><p>This document describes an 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.  This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc3119bis-05</draft>
        <obsoletes>
            <doc-id>RFC3119</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5219</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5220</doc-id>
        <title>Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules</title>
        <author>
            <name>A. Matsumoto</name>
        </author>
        <author>
            <name>T. Fujisaki</name>
        </author>
        <author>
            <name>R. Hiromi</name>
        </author>
        <author>
            <name>K. Kanayama</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>multiple prefixes</kw>
        </keywords>
        <abstract><p>A single physical link can have multiple prefixes assigned to it.  In that environment, end hosts might have multiple IP addresses and be required to use them selectively.  RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs.  But, it has been too difficult to use operationally for several reasons.  In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication.  This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-addr-select-ps-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5220</errata-url>
        <doi>10.17487/RFC5220</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5221</doc-id>
        <title>Requirements for Address Selection Mechanisms</title>
        <author>
            <name>A. Matsumoto</name>
        </author>
        <author>
            <name>T. Fujisaki</name>
        </author>
        <author>
            <name>R. Hiromi</name>
        </author>
        <author>
            <name>K. Kanayama</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>default address selection</kw>
        </keywords>
        <abstract><p>There are some problematic cases when using the default address selection mechanism that RFC 3484 defines.  This document describes additional requirements that operate with RFC 3484 to solve the problems.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-addr-select-req-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC5221</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5222</doc-id>
        <title>LoST: A Location-to-Service Translation Protocol</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>emergency services</kw>
            <kw>emergency call routing</kw>
        </keywords>
        <abstract><p>This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs.  In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ecrit-lost-10</draft>
        <updated-by>
            <doc-id>RFC6848</doc-id>
            <doc-id>RFC8917</doc-id>
            <doc-id>RFC9036</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5222</errata-url>
        <doi>10.17487/RFC5222</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5223</doc-id>
        <title>Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mapping service</kw>
            <kw>emergency service</kw>
            <kw>emergency communication</kw>
        </keywords>
        <abstract><p>The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.</p><p> This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ecrit-dhc-lost-discovery-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC5223</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5224</doc-id>
        <title>Diameter Policy Processing Application</title>
        <author>
            <name>M. Brenner</name>
        </author>
        <date>
            <month>March</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>policy evaluation</kw>
            <kw>or evaluation and enforcement</kw>
            <kw>pem-1</kw>
            <kw>peem</kw>
            <kw>oma</kw>
            <kw>open mobile alliance</kw>
        </keywords>
        <abstract><p>This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement).  This application is needed as one of the implementations of the Open Mobile Alliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-brenner-dime-peem-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5224</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5225</doc-id>
        <title>RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite</title>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>K. Sandlund</name>
        </author>
        <date>
            <month>April</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>rohc</kw>
            <kw>3095</kw>
            <kw>3843</kw>
            <kw>4019</kw>
        </keywords>
        <abstract><p>This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.</p><p> This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.</p><p> The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5225</errata-url>
        <doi>10.17487/RFC5225</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5226</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>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>internet assigned numbers authority</kw>
            <kw>values</kw>
            <kw>implementations</kw>
            <kw>code point</kw>
            <kw>protocol constant</kw>
            <kw>protocol parameter</kw>
        </keywords>
        <abstract><p>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</p><p> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</p><p> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-narten-iana-considerations-rfc2434bis-09</draft>
        <obsoletes>
            <doc-id>RFC2434</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8126</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5226</errata-url>
        <doi>10.17487/RFC5226</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5227</doc-id>
        <title>IPv4 Address Conflict Detection</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>internet protocol version 4</kw>
        </keywords>
        <abstract><p>When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts.  This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-cheshire-ipv4-acd-06</draft>
        <updates>
            <doc-id>RFC0826</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5227</errata-url>
        <doi>10.17487/RFC5227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5228</doc-id>
        <title>Sieve: An Email Filtering Language</title>
        <author>
            <name>P. Guenther</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Showalter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document describes a language for filtering email messages at time of final delivery.  It is designed to be implementable on either a mail client or mail server.  It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system.  It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-3028bis-13</draft>
        <obsoletes>
            <doc-id>RFC3028</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5229</doc-id>
            <doc-id>RFC5429</doc-id>
            <doc-id>RFC6785</doc-id>
            <doc-id>RFC9042</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5228</errata-url>
        <doi>10.17487/RFC5228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5229</doc-id>
        <title>Sieve Email Filtering: Variables Extension</title>
        <author>
            <name>K. Homme</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules.  This document updates the Sieve filtering language (RFC 5228) with an extension to support variables.  The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-variables-08</draft>
        <updates>
            <doc-id>RFC5228</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5173</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5229</errata-url>
        <doi>10.17487/RFC5229</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5230</doc-id>
        <title>Sieve Email Filtering: Vacation Extension</title>
        <author>
            <name>T. Showalter</name>
        </author>
        <author>
            <name>N. Freed</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>autoresponder</kw>
        </keywords>
        <abstract><p>This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages.  Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-vacation-06</draft>
        <updated-by>
            <doc-id>RFC8580</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5230</errata-url>
        <doi>10.17487/RFC5230</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5231</doc-id>
        <title>Sieve Email Filtering: Relational Extension</title>
        <author>
            <name>W. Segmuller</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>relational operators</kw>
        </keywords>
        <abstract><p>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.</p><p> This document obsoletes RFC 3431. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-3431bis-04</draft>
        <obsoletes>
            <doc-id>RFC3431</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5231</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5232</doc-id>
        <title>Sieve Email Filtering: Imap4flags Extension</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>imap</kw>
            <kw>internet message access control protocol</kw>
            <kw>imap flags</kw>
            <kw>imap system flags</kw>
            <kw>imap keywords</kw>
        </keywords>
        <abstract><p>Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.</p><p> This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-imapflags-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5232</errata-url>
        <doi>10.17487/RFC5232</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5233</doc-id>
        <title>Sieve Email Filtering: Subaddress Extension</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>subaddressing</kw>
            <kw>detailed addressing</kw>
            <kw>:user</kw>
            <kw>:detail</kw>
        </keywords>
        <abstract><p>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 Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-rfc3598bis-05</draft>
        <obsoletes>
            <doc-id>RFC3598</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5233</errata-url>
        <doi>10.17487/RFC5233</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5234</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>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ABNF</kw>
            <kw>backus-naur form</kw>
            <kw>augmented backus-naur form</kw>
            <kw>rule definitions</kw>
            <kw>encoding</kw>
            <kw>core lexical analyzer</kw>
        </keywords>
        <abstract><p>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-crocker-rfc4234bis-01</draft>
        <obsoletes>
            <doc-id>RFC4234</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7405</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0068</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5234</errata-url>
        <doi>10.17487/RFC5234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5235</doc-id>
        <title>Sieve Email Filtering: Spamtest and Virustest Extensions</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>January</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>spamtest</kw>
            <kw>spamtestplus</kw>
            <kw>virustest</kw>
            <kw>scores</kw>
        </keywords>
        <abstract><p>The Sieve email filtering language "spamtest", "spamtestplus", 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 proper input to the tests. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-spamtestbis-05</draft>
        <obsoletes>
            <doc-id>RFC3685</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5236</doc-id>
        <title>Improved Packet Reordering Metrics</title>
        <author>
            <name>A. Jayasumana</name>
        </author>
        <author>
            <name>N. Piratla</name>
        </author>
        <author>
            <name>T. Banka</name>
        </author>
        <author>
            <name>A. Bare</name>
        </author>
        <author>
            <name>R. Whitner</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>reorder density</kw>
            <kw>rd</kw>
            <kw>reorder buffer-occupancy density</kw>
            <kw>rbd</kw>
        </keywords>
        <abstract><p>This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.</p><p> These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-jayasumana-reorder-density-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5236</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5237</doc-id>
        <title>IANA Allocation Guidelines for the Protocol Field</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>February</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ipv4 header</kw>
            <kw>next header field</kw>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header.  It modifies the rules specified in RFC 2780 by removing the Expert Review option.  The change will also affect the allocation of Next Header field values in IPv6.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-arkko-rfc2780-proto-update-02</draft>
        <updates>
            <doc-id>RFC2780</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0037</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5237</errata-url>
        <doi>10.17487/RFC5237</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5238</doc-id>
        <title>Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)</title>
        <author>
            <name>T. Phelan</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>tls</kw>
            <kw>transport protocol</kw>
        </keywords>
        <abstract><p>This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP).  DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.  DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-dtls-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC5238</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5239</doc-id>
        <title>A Framework for Centralized Conferencing</title>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>C. Boulton</name>
        </author>
        <author>
            <name>O. Levin</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>call signaling</kw>
            <kw>call signalling</kw>
        </keywords>
        <abstract><p>This document defines the framework for Centralized Conferencing.  The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference.  The Centralized Conferencing Framework defines logical entities and naming conventions.  The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications.  The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xcon-framework-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5239</errata-url>
        <doi>10.17487/RFC5239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5240</doc-id>
        <title>Protocol Independent Multicast (PIM) Bootstrap Router MIB</title>
        <author>
            <name>B. Joshi</name>
        </author>
        <author>
            <name>R. Bijlani</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>bootstrap router</kw>
            <kw>bsr</kw>
            <kw>PIM-BSR-MIB</kw>
        </keywords>
        <abstract><p>This document 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 Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-bsr-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5240</errata-url>
        <doi>10.17487/RFC5240</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5241</doc-id>
        <title>Naming Rights in IETF Protocols</title>
        <author>
            <name>A. Falk</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>april fools</kw>
            <kw>field naming rights</kw>
        </keywords>
        <abstract><p>This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields.  This memo describes a process for assignment of rights and explores some of the issues associated with the process.  Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process.  This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5241</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5242</doc-id>
        <title>A Generalized Unified Character Code: Western European and CJK Sections</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>idn</kw>
            <kw>latin</kw>
            <kw>greek</kw>
            <kw>cyrilllic</kw>
            <kw>chinese</kw>
            <kw>internationalized domain names</kw>
        </keywords>
        <abstract><p>Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes.  This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters.  It is not a complete specification of that character set.  This memo provides information for the Internet community.</p></abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5242</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5243</doc-id>
        <title>OSPF Database Exchange Summary List Optimization</title>
        <author>
            <name>R. Ogier</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3.  In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor.  This optimization reduces Database Description overhead by about 50% in large networks.  This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ogier-ospf-dbex-opt-03</draft>
        <updated-by>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5243</errata-url>
        <doi>10.17487/RFC5243</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5244</doc-id>
        <title>Definition of Events for Channel-Oriented Telephony Signalling</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>event code</kw>
            <kw>telephony event rtp payload</kw>
        </keywords>
        <abstract><p>This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload.  It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833.  As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant.  In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling.  This document expands and improves the coverage of signalling systems compared to RFC 2833. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc2833biscas-05</draft>
        <updates>
            <doc-id>RFC4733</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5245</doc-id>
        <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>117</page-count>
        <abstract><p>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).  ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-ice-19</draft>
        <obsoletes>
            <doc-id>RFC4091</doc-id>
            <doc-id>RFC4092</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8445</doc-id>
            <doc-id>RFC8839</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6336</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5245</errata-url>
        <doi>10.17487/RFC5245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5246</doc-id>
        <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
        <author>
            <name>T. Dierks</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>104</page-count>
        <keywords>
            <kw>idea</kw>
            <kw>international data algorithm</kw>
            <kw>symmetric</kw>
            <kw>transport protocol layer</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security 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]</p></abstract>
        <draft>draft-ietf-tls-rfc4346-bis-10</draft>
        <obsoletes>
            <doc-id>RFC3268</doc-id>
            <doc-id>RFC4346</doc-id>
            <doc-id>RFC4366</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8446</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4492</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC5746</doc-id>
            <doc-id>RFC5878</doc-id>
            <doc-id>RFC6176</doc-id>
            <doc-id>RFC7465</doc-id>
            <doc-id>RFC7507</doc-id>
            <doc-id>RFC7568</doc-id>
            <doc-id>RFC7627</doc-id>
            <doc-id>RFC7685</doc-id>
            <doc-id>RFC7905</doc-id>
            <doc-id>RFC7919</doc-id>
            <doc-id>RFC8447</doc-id>
            <doc-id>RFC9155</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5246</errata-url>
        <doi>10.17487/RFC5246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5247</doc-id>
        <title>Extensible Authentication Protocol (EAP) Key Management Framework</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>D. Simon</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>extensible network access authentication</kw>
            <kw>key hierarchy</kw>
            <kw>methods</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication.  This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods".  It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-eap-keying-22</draft>
        <updates>
            <doc-id>RFC3748</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8940</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>eap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5247</errata-url>
        <doi>10.17487/RFC5247</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5248</doc-id>
        <title>A Registry for SMTP Enhanced Mail System Status Codes</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract><p>The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes.  While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes.  This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-hansen-4468upd-mailesc-registry-05</draft>
        <updates>
            <doc-id>RFC3463</doc-id>
            <doc-id>RFC4468</doc-id>
            <doc-id>RFC4954</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0138</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5248</errata-url>
        <doi>10.17487/RFC5248</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5249</doc-id>
        <title>Templates for Internet-Drafts Containing MIB Modules</title>
        <author>
            <name>D. Harrington</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>network management</kw>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>smiv2</kw>
            <kw>template</kw>
        </keywords>
        <abstract><p>This memo references three annotated templates for IETF documents that contain the definition of MIB modules.  It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-harrington-text-mib-doc-template-06</draft>
        <is-also>
            <doc-id>BCP0139</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5249</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5250</doc-id>
        <title>The OSPF Opaque LSA Option</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <author>
            <name>R. Coltun</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>OSPF-LSA]</kw>
            <kw>open shortest path first</kw>
            <kw>link state advertisement</kw>
            <kw>opaque lsas</kw>
        </keywords>
        <abstract><p>This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.</p><p> This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-rfc2370bis-05</draft>
        <obsoletes>
            <doc-id>RFC2370</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5250</errata-url>
        <doi>10.17487/RFC5250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5251</doc-id>
        <title>Layer 1 VPN Basic Mode</title>
        <author>
            <name>D. Fedyk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>R. Rabbat</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>virtual private network</kw>
            <kw>l1vpn</kw>
            <kw>l1vpn bm</kw>
        </keywords>
        <abstract><p>This document describes the Basic Mode of Layer 1 VPNs (L1VPNs).  L1VPN Basic Mode (L1VPN BM) is a port-based VPN.  In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology.  This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l1vpn-basic-mode-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l1vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5251</errata-url>
        <doi>10.17487/RFC5251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5252</doc-id>
        <title>OSPF-Based Layer 1 VPN Auto-Discovery</title>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>l1vpn</kw>
            <kw>layer 1 virtual private network</kw>
        </keywords>
        <abstract><p>This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism.  This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs.  This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l1vpn-ospf-auto-discovery-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l1vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5252</errata-url>
        <doi>10.17487/RFC5252</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5253</doc-id>
        <title>Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode</title>
        <author>
            <name>T. Takeda</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>gmpls</kw>
            <kw>generalized multiprotocol label switching</kw>
            <kw>l1vpn bm</kw>
        </keywords>
        <abstract><p>This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).</p><p> L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l1vpn-applicability-basic-mode-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l1vpn</wg_acronym>
        <doi>10.17487/RFC5253</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5254</doc-id>
        <title>Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)</title>
        <author>
            <name>N. Bitar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Bocci</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Pseudowire</kw>
            <kw>PWE3</kw>
            <kw>multi-segment</kw>
            <kw>MS-PW</kw>
            <kw>SS-PW</kw>
            <kw>S-PE</kw>
            <kw>T-PE</kw>
        </keywords>
        <abstract><p>This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains.  These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pwe3-ms-pw-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5254</errata-url>
        <doi>10.17487/RFC5254</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5255</doc-id>
        <title>Internet Message Access Protocol Internationalization</title>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>imap</kw>
            <kw>imapv4</kw>
            <kw>imap4</kw>
        </keywords>
        <abstract><p>Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings.  It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME).  This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imapext-i18n-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5255</errata-url>
        <doi>10.17487/RFC5255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5256</doc-id>
        <title>Internet Message Access Protocol - SORT and THREAD Extensions</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ordered subject references</kw>
            <kw>imap capability</kw>
        </keywords>
        <abstract><p>This document describes the base-level server-based sorting and threading extensions to the IMAP protocol.  These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imapext-sort-20</draft>
        <updated-by>
            <doc-id>RFC5957</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapext</wg_acronym>
        <doi>10.17487/RFC5256</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5257</doc-id>
        <title>Internet Message Access Protocol - ANNOTATE Extension</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>imap</kw>
        </keywords>
        <abstract><p>The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.</p><p> Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.</p><p> Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-imapext-annotate-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5257</errata-url>
        <doi>10.17487/RFC5257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5258</doc-id>
        <title>Internet Message Access Protocol version 4 - LIST Command Extensions</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>imap4 ,list</kw>
            <kw>lsub</kw>
            <kw>extended list</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible.  If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension.  This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imapext-list-extensions-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapext</wg_acronym>
        <doi>10.17487/RFC5258</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5259</doc-id>
        <title>Internet Message Access Protocol - CONVERT Extension</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Coates</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>Lemonade</kw>
            <kw>CONVERT</kw>
            <kw>conversion</kw>
            <kw>transcoding</kw>
        </keywords>
        <abstract><p>CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments.  Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-convert-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5259</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5260</doc-id>
        <title>Sieve Email Filtering: Date and Index Extensions</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>smtp</kw>
            <kw>esmtp</kw>
            <kw>date</kw>
            <kw>index</kw>
        </keywords>
        <abstract><p>This document describes the "date" and "index" extensions to the Sieve email filtering language.  The "date" extension gives Sieve the ability to test date and time values in various ways.  The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-freed-sieve-date-index-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5260</errata-url>
        <doi>10.17487/RFC5260</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5261</doc-id>
        <title>An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors</title>
        <author>
            <name>J. Urpalainen</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
        </keywords>
        <abstract><p>Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems.  In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed.  This document describes an XML patch framework utilizing XML Path language (XPath) selectors.  These selector values and updated new data content constitute the basis of patch operations described in this document.  In addition to them, with basic &amp;lt;add&amp;gt;, &amp;lt;replace&amp;gt;, and &amp;lt;remove&amp;gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-xml-patch-ops-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5261</errata-url>
        <doi>10.17487/RFC5261</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5262</doc-id>
        <title>Presence Information Data Format (PIDF) Extension for Partial Presence</title>
        <author>
            <name>M. Lonnfors</name>
        </author>
        <author>
            <name>E. Leppanen</name>
        </author>
        <author>
            <name>H. Khartabil</name>
        </author>
        <author>
            <name>J. Urpalainen</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information.  One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity.  In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network.  This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-partial-pidf-format-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC5262</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5263</doc-id>
        <title>Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information</title>
        <author>
            <name>M. Lonnfors</name>
        </author>
        <author>
            <name>J. Costa-Requena</name>
        </author>
        <author>
            <name>E. Leppanen</name>
        </author>
        <author>
            <name>H. Khartabil</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>pidf</kw>
            <kw>presence information data format</kw>
        </keywords>
        <abstract><p>By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF).  A PIDF document contains a set of elements, each representing a different aspect of the presence being reported.  When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered.  This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-partial-notify-10</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC5263</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5264</doc-id>
        <title>Publication of Partial Presence Information</title>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>M. Lonnfors</name>
        </author>
        <author>
            <name>E. Leppanen</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent.  Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update.  As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient.  Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system.  This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-partial-publish-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC5264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5265</doc-id>
        <title>Mobile IPv4 Traversal across IPsec-Based VPN Gateways</title>
        <author>
            <name>S. Vaarala</name>
        </author>
        <author>
            <name>E. Klovning</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>mobile ip</kw>
            <kw>mobile ipv4</kw>
            <kw>ipsec</kw>
            <kw>mipv4</kw>
        </keywords>
        <abstract><p>This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users.  The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-vpn-problem-solution-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC5265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5266</doc-id>
        <title>Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)</title>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise.  Secure connectivity is required when the user connects to the enterprise from an untrusted network.  Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address.  This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-mip4-mobike-connectivity-03</draft>
        <is-also>
            <doc-id>BCP0136</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC5266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5267</doc-id>
        <title>Contexts for IMAP4</title>
        <author>
            <name>D. Cridland</name>
        </author>
        <author>
            <name>C. King</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>imap4rev1</kw>
            <kw>esort</kw>
            <kw>context</kw>
        </keywords>
        <abstract><p>The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled.  This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-cridland-imap-context-05</draft>
        <updated-by>
            <doc-id>RFC5465</doc-id>
            <doc-id>RFC9394</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5268</doc-id>
        <title>Mobile IPv6 Fast Handovers</title>
        <author>
            <name>R. Koodli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>mipv6</kw>
            <kw>handover latency</kw>
        </keywords>
        <abstract><p>Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover.  During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations.  This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP).  Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well.  This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures.  This document does not address improving the link switching latency. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-fmipv6-rfc4068bis-07</draft>
        <obsoletes>
            <doc-id>RFC4068</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC5568</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5268</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5269</doc-id>
        <title>Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>fast binding update</kw>
        </keywords>
        <abstract><p>Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks.  In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling.  The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971).  The Mobile Node sends the public key to the Access Router.  The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node.  The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update.  The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange.  The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node.  This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-handover-key-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5270</doc-id>
        <title>Mobile IPv6 Fast Handovers over IEEE 802.16e Networks</title>
        <author>
            <name>H. Jang</name>
        </author>
        <author>
            <name>J. Jee</name>
        </author>
        <author>
            <name>Y. Han</name>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>J. Cha</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Mobile IPv6</kw>
            <kw> Handover optimization</kw>
            <kw>Cross-layer design</kw>
        </keywords>
        <abstract><p>This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications.  The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-fh80216e-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5270</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5271</doc-id>
        <title>Mobile IPv6 Fast Handovers for 3G CDMA Networks</title>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>FMIP</kw>
            <kw>handoff</kw>
            <kw>3GPP2</kw>
        </keywords>
        <abstract><p>Mobile IPv6 is designed to maintain its connectivity while moving from one network to another.  It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers.  However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network.  During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony.  This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-3gfh-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5271</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5272</doc-id>
        <title>Certificate Management over CMS (CMC)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>M. Myers</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>certificate management protocol</kw>
            <kw>cryptographic message syntax</kw>
            <kw>pki</kw>
            <kw>public key infrastructure</kw>
        </keywords>
        <abstract><p>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</p><p> 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</p><p> 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</p><p> CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-2797-bis-07</draft>
        <obsoletes>
            <doc-id>RFC2797</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6402</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5272</errata-url>
        <doi>10.17487/RFC5272</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5273</doc-id>
        <title>Certificate Management over CMS (CMC): Transport Protocols</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>M. Myers</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>cryptographic message syntax</kw>
            <kw>http</kw>
            <kw>file</kw>
            <kw>mail</kw>
            <kw>tcp</kw>
        </keywords>
        <abstract><p>This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages.  The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-cmc-trans-08</draft>
        <updated-by>
            <doc-id>RFC6402</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5273</errata-url>
        <doi>10.17487/RFC5273</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5274</doc-id>
        <title>Certificate Management Messages over CMS (CMC): Compliance Requirements</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>M. Myers</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>cryptographic message syntax</kw>
            <kw>cmc enrollment protocol</kw>
        </keywords>
        <abstract><p>This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol.  The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents.  This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-cmc-compl-05</draft>
        <updated-by>
            <doc-id>RFC6402</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC5274</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5275</doc-id>
        <title>CMS Symmetric Key Management and Distribution</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>June</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>89</page-count>
        <keywords>
            <kw>cryptographic message syntax</kw>
            <kw>symmetric cryptographic algorithms</kw>
            <kw>certificate management over cms</kw>
            <kw>cmc</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms.  Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms.  The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys.  Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key.  This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-symkeydist-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5275</errata-url>
        <doi>10.17487/RFC5275</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5276</doc-id>
        <title>Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records</title>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ERS</kw>
            <kw>Evidence Record</kw>
            <kw>SCVP</kw>
            <kw>Server-based Certificate Validation Protocol</kw>
            <kw>PKI artifact preservation</kw>
        </keywords>
        <abstract><p>The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server.  It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past.  The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data.  Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure.  This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ltans-ers-scvp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ltans</wg_acronym>
        <doi>10.17487/RFC5276</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5277</doc-id>
        <title>NETCONF Event Notifications</title>
        <author>
            <name>S. Chisholm</name>
        </author>
        <author>
            <name>H. Trevino</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>Extensible Markup Language</kw>
            <kw>NETCONF</kw>
            <kw>Event</kw>
            <kw>Asynchronous Message</kw>
            <kw>Notification</kw>
        </keywords>
        <abstract><p>This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF).  This is an optional capability built on top of the base NETCONF definition.  This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-notification-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5277</errata-url>
        <doi>10.17487/RFC5277</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5278</doc-id>
        <title>IANA Registration of Enumservices for Voice and Video Messaging</title>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>D. Troshynski</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>vmsg</kw>
            <kw>voicemsg</kw>
            <kw>videomsg</kw>
            <kw>unifmsg</kw>
            <kw>sip</kw>
            <kw>sips</kw>
            <kw>http</kw>
            <kw>https</kw>
            <kw>tel</kw>
        </keywords>
        <abstract><p>This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system.  This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg".  Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-vmsg-02</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5278</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5279</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)</title>
        <author>
            <name>A. Monrad</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>nid</kw>
            <kw>namespace identifier</kw>
            <kw>3gpp</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP).  3GPP defines and manages resources that utilize this URN name model.  Management activities for these and other resource types are provided by the 3GPP Support Team.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-monrad-sipping-3gpp-urn-namespace-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5279</errata-url>
        <doi>10.17487/RFC5279</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5280</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>D. Cooper</name>
        </author>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>S. Boeyen</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <date>
            <month>May</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>151</page-count>
        <keywords>
            <kw>X.509 v3</kw>
            <kw>X.509 v2</kw>
            <kw>certificate extensions</kw>
        </keywords>
        <abstract><p>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc3280bis-11</draft>
        <obsoletes>
            <doc-id>RFC3280</doc-id>
            <doc-id>RFC4325</doc-id>
            <doc-id>RFC4630</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6818</doc-id>
            <doc-id>RFC8398</doc-id>
            <doc-id>RFC8399</doc-id>
            <doc-id>RFC9549</doc-id>
            <doc-id>RFC9598</doc-id>
            <doc-id>RFC9608</doc-id>
            <doc-id>RFC9618</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5280</errata-url>
        <doi>10.17487/RFC5280</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5281</doc-id>
        <title>Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)</title>
        <author>
            <name>P. Funk</name>
        </author>
        <author>
            <name>S. Blake-Wilson</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>AAA</kw>
            <kw>Authentication</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase.  During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase.  During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel.  The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2.  Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.  The data phase may also be used for additional, arbitrary data exchange.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-funk-eap-ttls-v0-05</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9427</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5281</errata-url>
        <doi>10.17487/RFC5281</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5282</doc-id>
        <title>Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>encryption cipher</kw>
            <kw>combined mode algorithms</kw>
            <kw>aes gcm</kw>
            <kw>advanced encryption standard in galois/counter mode</kw>
            <kw>aes ccm</kw>
            <kw>aes in couner with cbc-mac mode</kw>
        </keywords>
        <abstract><p>An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.</p><p> The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-black-ipsec-ikev2-aead-modes-01</draft>
        <updates>
            <doc-id>RFC4306</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5282</errata-url>
        <doi>10.17487/RFC5282</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5283</doc-id>
        <title>LDP Extension for Inter-Area Label Switched Paths (LSPs)</title>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>LDP label mapping procedures</kw>
            <kw>longest-match</kw>
            <kw>prefix aggregation</kw>
        </keywords>
        <abstract><p>To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).</p><p> This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-interarea-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5283</errata-url>
        <doi>10.17487/RFC5283</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5284</doc-id>
        <title>User-Defined Errors for RSVP</title>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>resource reservation protocol</kw>
            <kw>user_error_spec</kw>
            <kw>error_spec</kw>
        </keywords>
        <abstract><p>The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.</p><p> This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-user-error-spec-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5284</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5285</doc-id>
        <title>A General Mechanism for RTP Header Extensions</title>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>H. Desineni</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>extmap</kw>
        </keywords>
        <abstract><p>This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol).  It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized.  The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-hdrext-15</draft>
        <obsoleted-by>
            <doc-id>RFC8285</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5285</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5286</doc-id>
        <title>Basic Specification for IP Fast Reroute: Loop-Free Alternates</title>
        <author>
            <name>A. Atlas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Zinin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>FRR</kw>
            <kw>LFA</kw>
            <kw>recovery</kw>
            <kw>failure</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG).  The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure.  Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.  This simple approach does not require any support from other routers.  The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rtgwg-ipfrr-spec-base-12</draft>
        <updated-by>
            <doc-id>RFC8518</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5286</errata-url>
        <doi>10.17487/RFC5286</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5287</doc-id>
        <title>Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks</title>
        <author>
            <name>A. Vainshtein</name>
        </author>
        <author>
            <name>Y(J). Stein</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>pwe3</kw>
            <kw>pseudowire emulation edge-to-edge</kw>
            <kw>tdmoip</kw>
            <kw>tdm options</kw>
        </keywords>
        <abstract><p>This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-tdm-control-protocol-extensi-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5288</doc-id>
        <title>AES Galois Counter Mode (GCM) Cipher Suites for TLS</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>A. Choudhury</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>advanced encryption standard</kw>
            <kw>transport layer security</kw>
            <kw>data origin</kw>
            <kw>confidentiality</kw>
        </keywords>
        <abstract><p>This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation.  GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.  This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-rsa-aes-gcm-03</draft>
        <updated-by>
            <doc-id>RFC9325</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5288</errata-url>
        <doi>10.17487/RFC5288</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5289</doc-id>
        <title>TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>transport layer security</kw>
            <kw>mac algorithm</kw>
        </keywords>
        <abstract><p>RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS).  However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm.  This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms.  Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tls-ecc-new-mac-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC5289</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5290</doc-id>
        <title>Comments on the Usefulness of Simple Best-Effort Traffic</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>flow-rate fairness</kw>
        </keywords>
        <abstract><p>This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like.  One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping.  While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic.  A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-floyd-tsvwg-besteffort-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5290</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5291</doc-id>
        <title>Outbound Route Filtering Capability for BGP-4</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>border gatway protocol</kw>
            <kw>orf</kw>
        </keywords>
        <abstract><p>This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-route-filter-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5291</errata-url>
        <doi>10.17487/RFC5291</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5292</doc-id>
        <title>Address-Prefix-Based Outbound Route Filter for BGP-4</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>S. Sangli</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>orf</kw>
            <kw>border gateway protocol</kw>
            <kw>Address Prefix Outbound Route Filter</kw>
        </keywords>
        <abstract><p>This document defines a new Outbound Router Filter (ORF) type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering.  This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-bgp-prefix-orf-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC5292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5293</doc-id>
        <title>Sieve Email Filtering: Editheader Extension</title>
        <author>
            <name>J. Degener</name>
        </author>
        <author>
            <name>P. Guenther</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>addheadaer</kw>
            <kw>deleteheader</kw>
        </keywords>
        <abstract><p>This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-editheader-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5293</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5294</doc-id>
        <title>Host Threats to Protocol Independent Multicast (PIM)</title>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>J. Lingard</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>security threat analysis</kw>
        </keywords>
        <abstract><p>This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pim-lasthop-threats-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC5294</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5295</doc-id>
        <title>Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>L. Dondeti</name>
        </author>
        <author>
            <name>V. Narayanan</name>
        </author>
        <author>
            <name>M. Nakhjiri</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>EAP keying</kw>
            <kw>EMSK</kw>
            <kw>DSRK</kw>
            <kw>DSUSRK</kw>
            <kw>Domain-Specific Key Derivation</kw>
            <kw>Usage-Specific Key Derivation</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses.  This memo reserves the EMSK for the sole purpose of deriving root keys.  Root keys are master keys that can be used for multiple purposes, identified by usage definitions.  This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation.  Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hokey-emsk-hierarchy-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5295</errata-url>
        <doi>10.17487/RFC5295</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5296</doc-id>
        <title>EAP Extensions for EAP Re-authentication Protocol (ERP)</title>
        <author>
            <name>V. Narayanan</name>
        </author>
        <author>
            <name>L. Dondeti</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>extensible authentication protocol</kw>
            <kw>authentication modes</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.  In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator.  This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.  The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hokey-erx-14</draft>
        <obsoleted-by>
            <doc-id>RFC6696</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5296</errata-url>
        <doi>10.17487/RFC5296</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5297</doc-id>
        <title>Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)</title>
        <author>
            <name>D. Harkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>authenticated encryption</kw>
            <kw>key wrapping</kw>
            <kw>key derivation</kw>
            <kw>block cipher</kw>
            <kw>pseudo-random function</kw>
        </keywords>
        <abstract><p>This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation.  SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted.  It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector.  Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dharkins-siv-aes-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5298</doc-id>
        <title>Analysis of Inter-Domain Label Switched Path (LSP) Recovery</title>
        <author>
            <name>T. Takeda</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ikejiri</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>gmpls</kw>
            <kw>multi-domain environment</kw>
            <kw>end-to-end diverse Traffic Engineering LSPs</kw>
        </keywords>
        <abstract><p>Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.</p><p> Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".</p><p> This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-inter-domain-recovery-analysis-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5298</errata-url>
        <doi>10.17487/RFC5298</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5299</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5300</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5301</doc-id>
        <title>Dynamic Hostname Exchange Mechanism for IS-IS</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
            <kw>routers</kw>
            <kw>tlv</kw>
            <kw>name-to-systemID</kw>
        </keywords>
        <abstract><p>RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.</p><p> This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-rfc2763bis-00</draft>
        <obsoletes>
            <doc-id>RFC2763</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6232</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5301</errata-url>
        <doi>10.17487/RFC5301</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5302</doc-id>
        <title>Domain-Wide Prefix Distribution with Two-Level IS-IS</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>H. Smit</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
            <kw>routers</kw>
            <kw>loops</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.</p><p> This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-rfc2966bis-03</draft>
        <obsoletes>
            <doc-id>RFC2966</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1195</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5302</errata-url>
        <doi>10.17487/RFC5302</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5303</doc-id>
        <title>Three-Way Handshake for IS-IS Point-to-Point Adjacencies</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>R. Saluja</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
        </keywords>
        <abstract><p>The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.</p><p> Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.</p><p> This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-rfc3373bis-01</draft>
        <obsoletes>
            <doc-id>RFC3373</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5303</errata-url>
        <doi>10.17487/RFC5303</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5304</doc-id>
        <title>IS-IS Cryptographic Authentication</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
            <kw>IS-IS authentication</kw>
            <kw>MD5</kw>
            <kw>HMAC-MD5</kw>
            <kw>security</kw>
            <kw>routing</kw>
            <kw>iso</kw>
            <kw>international standards organization</kw>
        </keywords>
        <abstract><p>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 replaces RFC 3567.</p><p> 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. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-rfc3567bis-03</draft>
        <obsoletes>
            <doc-id>RFC3567</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1195</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6233</doc-id>
            <doc-id>RFC6232</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5305</doc-id>
        <title>IS-IS Extensions for Traffic Engineering</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>H. Smit</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
            <kw>te</kw>
            <kw>router</kw>
            <kw>lsp  data units</kw>
            <kw>link state protocol data units</kw>
        </keywords>
        <abstract><p>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 Data Units (LSP).  This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-te-bis-00</draft>
        <obsoletes>
            <doc-id>RFC3784</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5307</doc-id>
            <doc-id>RFC8918</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5306</doc-id>
        <title>Restart Signaling for IS-IS</title>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
            <kw>LSP database synchronization</kw>
            <kw>Link State</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract><p>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.</p><p> This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-rfc3847bis-00</draft>
        <obsoletes>
            <doc-id>RFC3847</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8706</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5306</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5307</doc-id>
        <title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
        <author>
            <name>K. Kompella</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
        </keywords>
        <abstract><p>This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-rfc4205bis-00</draft>
        <obsoletes>
            <doc-id>RFC4205</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5305</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6001</doc-id>
            <doc-id>RFC6002</doc-id>
            <doc-id>RFC7074</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5307</errata-url>
        <doi>10.17487/RFC5307</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5308</doc-id>
        <title>Routing IPv6 with IS-IS</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
            <kw>tlv</kw>
            <kw>osi</kw>
        </keywords>
        <abstract><p>This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol.  The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain.  Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-ipv6-07</draft>
        <updated-by>
            <doc-id>RFC7775</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5308</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5309</doc-id>
        <title>Point-to-Point Operation over LAN in Link State Routing Protocols</title>
        <author>
            <name>N. Shen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Zinin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>broadcast</kw>
        </keywords>
        <abstract><p>The two predominant circuit types used by link state routing protocols are point-to-point and broadcast.  It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically.  This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-isis-igp-p2p-over-lan-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5309</errata-url>
        <doi>10.17487/RFC5309</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5310</doc-id>
        <title>IS-IS Generic Cryptographic Authentication</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>M. Fanto</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IS-IS</kw>
            <kw>Security</kw>
            <kw>HMAC-SHA</kw>
            <kw>Cryptographic Authentication</kw>
        </keywords>
        <abstract><p>This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.</p><p> Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-hmac-sha-07</draft>
        <updated-by>
            <doc-id>RFC6233</doc-id>
            <doc-id>RFC6232</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5310</errata-url>
        <doi>10.17487/RFC5310</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5311</doc-id>
        <title>Simplified Extension of Link State PDU (LSP) Space for IS-IS</title>
        <author>
            <name>D. McPherson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit.  This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-wg-extlsp-05</draft>
        <obsoletes>
            <doc-id>RFC3786</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC5311</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5312</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5313</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5314</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5315</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5316</doc-id>
        <title>ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>X. Duan</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>generalized mpls</kw>
            <kw>gmpls-te</kw>
            <kw>mpls-te</kw>
            <kw>isis-te</kw>
            <kw>flooding</kw>
        </keywords>
        <abstract><p>This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.</p><p> No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-isis-interas-te-extension-04</draft>
        <obsoleted-by>
            <doc-id>RFC9346</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5316</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5317</doc-id>
        <title>Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ITU-T</kw>
            <kw>MPLS-TP</kw>
            <kw>JWT</kw>
            <kw>GMPLS</kw>
            <kw>agreement</kw>
            <kw>PWE3</kw>
            <kw>OAM</kw>
            <kw>transport network</kw>
        </keywords>
        <abstract><p>This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks.  The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process.  This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-bryant-mpls-tp-jwt-report-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5317</errata-url>
        <doi>10.17487/RFC5317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5318</doc-id>
        <title>The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)</title>
        <author>
            <name>J. Hautakorpi</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>oma</kw>
            <kw>open mobile alliance</kw>
            <kw>push to talk over cellular</kw>
            <kw>poc</kw>
        </keywords>
        <abstract><p>This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header).  This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system.  It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists.  This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-hautakorpi-sipping-uri-list-handling-refused-03</draft>
        <updated-by>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5318</errata-url>
        <doi>10.17487/RFC5318</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5319</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5320</doc-id>
        <title>The Subnetwork Encapsulation and Adaptation Layer (SEAL)</title>
        <author>
            <name>F. Templin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>virtual topologies</kw>
            <kw>mtu</kw>
            <kw>maximum transmission units</kw>
        </keywords>
        <abstract><p>For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes.  These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs).  This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-templin-seal-23</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5320</errata-url>
        <doi>10.17487/RFC5320</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5321</doc-id>
        <title>Simple Mail Transfer Protocol</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>SMTP]</kw>
        </keywords>
        <abstract><p>This document is a specification of the basic protocol for Internet electronic mail transport.  It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete.  It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions.  Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-klensin-rfc2821bis-11</draft>
        <obsoletes>
            <doc-id>RFC2821</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1123</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7504</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5321</errata-url>
        <doi>10.17487/RFC5321</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5322</doc-id>
        <title>Internet Message Format</title>
        <author>
            <name>P. Resnick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>MAIL]</kw>
            <kw>e-mail</kw>
            <kw>email</kw>
            <kw>electronic mail</kw>
            <kw>header</kw>
            <kw>address</kw>
            <kw>mailbox</kw>
            <kw>reply</kw>
            <kw>forward</kw>
            <kw>resend</kw>
            <kw>resent</kw>
            <kw>folding</kw>
            <kw>Date</kw>
            <kw>From</kw>
            <kw>Sender</kw>
            <kw>Reply-To</kw>
            <kw>To</kw>
            <kw>Cc</kw>
            <kw>Bcc</kw>
            <kw>Message-ID</kw>
            <kw>In-Reply-To</kw>
            <kw>References</kw>
            <kw>Subject</kw>
            <kw>Comments</kw>
            <kw>Keywords</kw>
            <kw>Resent-Date</kw>
            <kw>Resent-From</kw>
            <kw>Resent-Sender</kw>
            <kw>Resent-To</kw>
            <kw>Resent-Cc</kw>
            <kw>Resent-Bcc</kw>
            <kw>Resent-Reply-To</kw>
            <kw>Resent-Message-ID</kw>
            <kw>Return-Path</kw>
            <kw>Received</kw>
        </keywords>
        <abstract><p>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-resnick-2822upd-06</draft>
        <obsoletes>
            <doc-id>RFC2822</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4021</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6854</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5322</errata-url>
        <doi>10.17487/RFC5322</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5323</doc-id>
        <title>Web Distributed Authoring and Versioning (WebDAV) SEARCH</title>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Reddy</name>
        </author>
        <author>
            <name>J. Davis</name>
        </author>
        <author>
            <name>A. Babich</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>Query</kw>
            <kw>Properties</kw>
        </keywords>
        <abstract><p>This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-reschke-webdav-search-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5324</doc-id>
        <title>MIB for Fibre-Channel Security Protocols (FC-SP)</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <author>
            <name>F. Maino</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>216</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>T11-FC-SP-TC-MIB</kw>
            <kw>T11-FC-SP-AUTHENTICATION-MIB</kw>
            <kw>T11-FC-SP-ZONING-MIB</kw>
            <kw>T11-FC-SP-POLICY-MIB</kw>
            <kw>T11-FC-SP-SA-MIB</kw>
        </keywords>
        <abstract><p>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 FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imss-fc-fcsp-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>imss</wg_acronym>
        <doi>10.17487/RFC5324</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5325</doc-id>
        <title>Licklider Transmission Protocol - Motivation</title>
        <author>
            <name>S. Burleigh</name>
        </author>
        <author>
            <name>M. Ramadas</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>ltp</kw>
            <kw>round-trip times</kw>
            <kw>long-haul</kw>
        </keywords>
        <abstract><p>This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.</p><p> In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes.</p><p> This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-ltp-motivation-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5326</doc-id>
        <title>Licklider Transmission Protocol - Specification</title>
        <author>
            <name>M. Ramadas</name>
        </author>
        <author>
            <name>S. Burleigh</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>ltp</kw>
            <kw>round-trip times</kw>
            <kw>rtt</kw>
            <kw>long-haul</kw>
        </keywords>
        <abstract><p>This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.</p><p> This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-ltp-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5326</errata-url>
        <doi>10.17487/RFC5326</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5327</doc-id>
        <title>Licklider Transmission Protocol - Security Extensions</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>M. Ramadas</name>
        </author>
        <author>
            <name>S. Burleigh</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ltp</kw>
            <kw>radio frequency</kw>
            <kw>automatic repeat request</kw>
            <kw>arq</kw>
        </keywords>
        <abstract><p>The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.</p><p> This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-ltp-extensions-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5327</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5328</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)</title>
        <author>
            <name>A. Adolf</name>
        </author>
        <author>
            <name>P. MacAvock</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>tv</kw>
            <kw>television</kw>
            <kw>digital television</kw>
            <kw>mpeg-2</kw>
            <kw>iptv</kw>
            <kw>multimedia</kw>
            <kw>content guide</kw>
            <kw>program guide</kw>
            <kw>metadata</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB 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 DVB.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-adolf-dvb-urn-05</draft>
        <updated-by>
            <doc-id>RFC7354</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5328</errata-url>
        <doi>10.17487/RFC5328</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5329</doc-id>
        <title>Traffic Engineering Extensions to OSPF Version 3</title>
        <author>
            <name>K. Ishiguro</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>A. Davey</name>
        </author>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>ospfv3</kw>
            <kw>te</kw>
        </keywords>
        <abstract><p>This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE).  This document extends OSPFv2 TE to handle IPv6 networks.  A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-traffic-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC5329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5330</doc-id>
        <title>A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Meyer</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <author>
            <name>A. Bonda</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>te</kw>
            <kw>lsp</kw>
        </keywords>
        <abstract><p>Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on.  By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths.  This requires knowledge of the number of unconstrained TE LSPs signalled across a link.  This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-number-0-bw-te-lsps-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5330</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5331</doc-id>
        <title>MPLS Upstream Label Assignment and Context-Specific Label Space</title>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>upstream-assigned mpls labels</kw>
        </keywords>
        <abstract><p>RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels.  This document introduces the notion of upstream-assigned MPLS labels.  It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-upstream-label-07</draft>
        <updated-by>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5331</errata-url>
        <doi>10.17487/RFC5331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5332</doc-id>
        <title>MPLS Multicast Encapsulations</title>
        <author>
            <name>T. Eckert</name>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>August</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>data link layer codepoint</kw>
            <kw>multiaccess media</kw>
            <kw>upstream-assigned label</kw>
            <kw>mac da</kw>
            <kw>medium access layer destination address</kw>
        </keywords>
        <abstract><p>RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".</p><p> RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.</p><p> This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-multicast-encaps-10</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
            <doc-id>RFC4023</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5332</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5333</doc-id>
        <title>IANA Registration of Enumservices for Internet Calendaring</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ENUM</kw>
            <kw>iCal</kw>
            <kw>iMIP</kw>
            <kw>i TIP</kw>
            <kw>CalDAV</kw>
        </keywords>
        <abstract><p>This document registers Enumservices for Internet calendaring.  Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-calendar-service-04</draft>
        <updated-by>
            <doc-id>RFC6118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5333</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5334</doc-id>
        <title>Ogg Media Types</title>
        <author>
            <name>I. Goncalves</name>
        </author>
        <author>
            <name>S. Pfeiffer</name>
        </author>
        <author>
            <name>C. Montgomery</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Ogg</kw>
            <kw>MIME</kw>
            <kw>Video</kw>
            <kw>Audio</kw>
            <kw>Codecs</kw>
        </keywords>
        <abstract><p>This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types.  This document obsoletes RFC 3534. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-goncalves-rfc3534bis-07</draft>
        <obsoletes>
            <doc-id>RFC3534</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7845</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5334</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5335</doc-id>
        <title>Internationalized Email Headers</title>
        <author>
            <name>A. Yang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>unicode</kw>
            <kw>utf-8</kw>
        </keywords>
        <abstract><p>Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses.  It also requires being able to express those addresses and the information based on them in mail header fields.  This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.  This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification.  This specification Updates section 6.4 of RFC 2045 to conform with the requirements.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-utf8headers-12</draft>
        <obsoleted-by>
            <doc-id>RFC6532</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2045</doc-id>
            <doc-id>RFC2822</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5335</errata-url>
        <doi>10.17487/RFC5335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5336</doc-id>
        <title>SMTP Extension for Internationalized Email Addresses</title>
        <author>
            <name>J. Yao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Mao</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>UTF8SMTP</kw>
            <kw>MAIL</kw>
            <kw>TRANSFER</kw>
        </keywords>
        <abstract><p>This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information.  Communication with systems that do not implement this specification is specified in another document.  This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-smtpext-13</draft>
        <obsoleted-by>
            <doc-id>RFC6531</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2821</doc-id>
            <doc-id>RFC2822</doc-id>
            <doc-id>RFC4952</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5336</errata-url>
        <doi>10.17487/RFC5336</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5337</doc-id>
        <title>Internationalized Delivery Status and Disposition Notifications</title>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>DSN</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.</p><p> This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-dsn-06</draft>
        <obsoleted-by>
            <doc-id>RFC6533</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3461</doc-id>
            <doc-id>RFC3462</doc-id>
            <doc-id>RFC3464</doc-id>
            <doc-id>RFC3798</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5337</errata-url>
        <doi>10.17487/RFC5337</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5338</doc-id>
        <title>Using the Host Identity Protocol with Legacy Applications</title>
        <author>
            <name>T. Henderson</name>
        </author>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>M. Komu</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>hip</kw>
            <kw>cryptographic name space</kw>
            <kw>network stack names</kw>
            <kw>api</kw>
            <kw>application programming interface</kw>
        </keywords>
        <abstract><p>This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP).  HIP proposes to add a cryptographic name space for network stack names.  From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded.  This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-applications-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC5338</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5339</doc-id>
        <title>Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)</title>
        <author>
            <name>JL. Le Roux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>general multiprotocol label switching</kw>
        </keywords>
        <abstract><p>This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs).  In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-mln-eval-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5339</errata-url>
        <doi>10.17487/RFC5339</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5340</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>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>July</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>ospfv3</kw>
        </keywords>
        <abstract><p>This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).</p><p> Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).</p><p> Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.</p><p> All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-update-23</draft>
        <obsoletes>
            <doc-id>RFC2740</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6845</doc-id>
            <doc-id>RFC6860</doc-id>
            <doc-id>RFC7503</doc-id>
            <doc-id>RFC8362</doc-id>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5340</errata-url>
        <doi>10.17487/RFC5340</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5341</doc-id>
        <title>The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>uniform resource locator</kw>
            <kw>schemes</kw>
        </keywords>
        <abstract><p>This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values.  It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-iptel-tel-reg-06</draft>
        <updates>
            <doc-id>RFC3966</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>iptel</wg_acronym>
        <doi>10.17487/RFC5341</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5342</doc-id>
        <title>IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Ethernet</kw>
            <kw>Ethertype</kw>
            <kw>802</kw>
            <kw>OUI</kw>
            <kw>EUI</kw>
            <kw>LSAP</kw>
        </keywords>
        <abstract><p>Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters.  This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-eastlake-ethernet-iana-considerations-08</draft>
        <obsoleted-by>
            <doc-id>RFC7042</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2153</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5342</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5343</doc-id>
        <title>Simple Network Management Protocol (SNMP) Context EngineID Discovery</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>snmpv3</kw>
            <kw>snmpengineid</kw>
            <kw>localengineid</kw>
        </keywords>
        <abstract><p>The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.</p><p> This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.</p><p> This document updates RFC 3411. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opsawg-snmp-engineid-discovery-03</draft>
        <updates>
            <doc-id>RFC3411</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0078</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC5343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5344</doc-id>
        <title>Presence and Instant Messaging Peering Use Cases</title>
        <author>
            <name>A. Houri</name>
        </author>
        <author>
            <name>E. Aoki</name>
        </author>
        <author>
            <name>S. Parameswar</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>non-voip</kw>
            <kw>collaboration service</kw>
            <kw>instant messaging</kw>
            <kw>im</kw>
        </keywords>
        <abstract><p>This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers.  These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network.  The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-speermint-consolidated-presence-im-usecases-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speermint</wg_acronym>
        <doi>10.17487/RFC5344</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5345</doc-id>
        <title>Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>large-scale snmp</kw>
            <kw>irtf</kw>
            <kw>nmrg</kw>
            <kw>network management research group</kw>
        </keywords>
        <abstract><p>The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.</p><p> This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.</p><p> This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-irtf-nmrg-snmp-measure-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5345</errata-url>
        <doi>10.17487/RFC5345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5346</doc-id>
        <title>Operational Requirements for ENUM-Based Softswitch Use</title>
        <author>
            <name>J. Lim</name>
        </author>
        <author>
            <name>W. Kim</name>
        </author>
        <author>
            <name>C. Park</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Applications</kw>
            <kw>ENUM</kw>
            <kw>DNS</kw>
            <kw>E.164</kw>
            <kw>NAPTR</kw>
            <kw>Softswitch</kw>
            <kw>Field Trial</kw>
        </keywords>
        <abstract><p>This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.</p><p> These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-enum-softswitch-req-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5346</errata-url>
        <doi>10.17487/RFC5346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5347</doc-id>
        <title>Media Gateway Control Protocol Fax Package</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>D. Hancock</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>mgcp</kw>
            <kw>fax calls</kw>
            <kw>fax relay</kw>
            <kw>fax transmission</kw>
        </keywords>
        <abstract><p>This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls.  The package allows for fax calls to be supported in two different ways.  The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent.  The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-andreasen-mgcp-fax-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5347</errata-url>
        <doi>10.17487/RFC5347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5348</doc-id>
        <title>TCP Friendly Rate Control (TFRC): Protocol Specification</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Padhye</name>
        </author>
        <author>
            <name>J. Widmer</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>tcp-friendly rate control</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>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 streaming media where a relatively smooth sending rate is of importance.</p><p> This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-rfc3448bis-06</draft>
        <obsoletes>
            <doc-id>RFC3448</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4342</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5348</errata-url>
        <doi>10.17487/RFC5348</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5349</doc-id>
        <title>Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>K. Jaganathan</name>
        </author>
        <author>
            <name>K. Lauter</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ecdh</kw>
            <kw>elliptic curve diffie-hellman</kw>
        </keywords>
        <abstract><p>This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-zhu-pkinit-ecc-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC5349</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5350</doc-id>
        <title>IANA Considerations for the IPv4 and IPv6 Router Alert Options</title>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>A. McDonald</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-manner-router-alert-iana-03</draft>
        <updates>
            <doc-id>RFC2113</doc-id>
            <doc-id>RFC3175</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5350</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5351</doc-id>
        <title>An Overview of Reliable Server Pooling Protocols</title>
        <author>
            <name>P. Lei</name>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>T. Dreibholz</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>rserpool</kw>
        </keywords>
        <abstract><p>The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications.  This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-overview-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5351</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5352</doc-id>
        <title>Aggregate Server Access Protocol (ASAP)</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>M. Stillman</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>rserpool</kw>
            <kw>enrp</kw>
            <kw>endpoint handlespace redundancy protocol</kw>
        </keywords>
        <abstract><p>Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.</p><p> In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.</p><p> ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.</p><p> The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-asap-21</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5353</doc-id>
        <title>Endpoint Handlespace Redundancy Protocol (ENRP)</title>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Stillman</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>A. Silverton</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>rserpool</kw>
            <kw>asap</kw>
            <kw>aggregate server access protocol</kw>
            <kw>fault-tolerant registry</kw>
        </keywords>
        <abstract><p>The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture.  Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-enrp-21</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5353</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5354</doc-id>
        <title>Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>M. Stillman</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>rserpool</kw>
        </keywords>
        <abstract><p>This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-common-param-18</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5354</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5355</doc-id>
        <title>Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats</title>
        <author>
            <name>M. Stillman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gopal</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>S. Sengodan</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool.  This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-threats-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5355</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5356</doc-id>
        <title>Reliable Server Pooling Policies</title>
        <author>
            <name>T. Dreibholz</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <date>
            <month>September</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>rserpool</kw>
            <kw>enrp</kw>
            <kw>endpoint handlespace redundancy protocol</kw>
        </keywords>
        <abstract><p>This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-policies-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5356</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5357</doc-id>
        <title>A Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>K. Hedayat</name>
        </author>
        <author>
            <name>R. Krzanowski</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>K. Yum</name>
        </author>
        <author>
            <name>J. Babiarz</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>two-way measaurement</kw>
            <kw>round-trip measurement</kw>
        </keywords>
        <abstract><p>The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices.  OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements.  However, it does not accommodate round-trip or two-way measurements.  This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities.  The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-twamp-09</draft>
        <updated-by>
            <doc-id>RFC5618</doc-id>
            <doc-id>RFC5938</doc-id>
            <doc-id>RFC6038</doc-id>
            <doc-id>RFC7717</doc-id>
            <doc-id>RFC7750</doc-id>
            <doc-id>RFC8545</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5357</errata-url>
        <doi>10.17487/RFC5357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5358</doc-id>
        <title>Preventing Use of Recursive Nameservers in Reflector Attacks</title>
        <author>
            <name>J. Damas</name>
        </author>
        <author>
            <name>F. Neves</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>denial of service</kw>
            <kw>dos</kw>
        </keywords>
        <abstract><p>This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks.  It provides recommended configuration as measures to mitigate the attack.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-dnsop-reflectors-are-evil-06</draft>
        <is-also>
            <doc-id>BCP0140</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC5358</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5359</doc-id>
        <title>Session Initiation Protocol Service Examples</title>
        <author>
            <name>A. Johnston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>C. Cunningham</name>
        </author>
        <author>
            <name>S. Donovan</name>
        </author>
        <author>
            <name>K. Summers</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>170</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>pbx</kw>
            <kw>centrex</kw>
            <kw>features</kw>
            <kw>hold</kw>
            <kw>transfer</kw>
            <kw>forwarding</kw>
            <kw>screening</kw>
            <kw>park</kw>
            <kw>pickup</kw>
            <kw>redial</kw>
            <kw>click</kw>
            <kw>call flows</kw>
        </keywords>
        <abstract><p>This document gives examples of Session Initiation Protocol (SIP) services.  This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features.  Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy.  Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields.  These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-sipping-service-examples-15</draft>
        <is-also>
            <doc-id>BCP0144</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5359</errata-url>
        <doi>10.17487/RFC5359</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5360</doc-id>
        <title>A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>G. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Willis</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence.  In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient.  Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks.  This document identifies a framework for consent-based communications in SIP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-consent-framework-04</draft>
        <updated-by>
            <doc-id>RFC8217</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5360</errata-url>
        <doi>10.17487/RFC5360</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5361</doc-id>
        <title>A Document Format for Requesting Consent</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>premission document</kw>
        </keywords>
        <abstract><p>This document defines an Extensible Markup Language (XML) format for a permission document used to request consent.  A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-consent-format-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5362</doc-id>
        <title>The Session Initiation Protocol (SIP) Pending Additions Event Package</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>consent-related</kw>
            <kw>resource list</kw>
        </keywords>
        <abstract><p>This document defines the SIP Pending Additions event package.  This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-pending-additions-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5362</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5363</doc-id>
        <title>Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the need for SIP URI-list services and provides requirements for their invocation.  Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-uri-services-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5363</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5364</doc-id>
        <title>Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>copy</kw>
            <kw>control</kw>
            <kw>resource</kw>
            <kw>list</kw>
        </keywords>
        <abstract><p>In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs).  The sender sends a single SIP request to a server which further distributes the request to the group.  This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request.  This URI list is expressed as a resource list XML document.  This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-capacity-attribute-07</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5364</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5365</doc-id>
        <title>Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>user agent client</kw>
            <kw>uac</kw>
            <kw>sip message request</kw>
            <kw>uniform resource identifier list</kw>
            <kw>message uri list</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service.  The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-uri-list-message-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5366</doc-id>
        <title>Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>sip uri list</kw>
            <kw>invite-contatined uri</kw>
        </keywords>
        <abstract><p>This document describes how to create a conference using SIP URI-list services.  In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-uri-list-conferencing-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5367</doc-id>
        <title>Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A.B. Roach</name>
        </author>
        <author>
            <name>O. Levin</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>subscribe request</kw>
            <kw>resrouce list</kw>
        </keywords>
        <abstract><p>This document specifies a way to create subscription to a list of resources in SIP.  This is achieved by including the list of resources in the body of a SUBSCRIBE request.  Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-uri-list-subscribe-02</draft>
        <updates>
            <doc-id>RFC3265</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5367</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5368</doc-id>
        <title>Referring to Multiple Resources in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>M. Isomaki</name>
        </author>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>H. Khartabil</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>sip refer</kw>
            <kw>refer-to</kw>
            <kw>multipler-refer</kw>
        </keywords>
        <abstract><p>This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request.  These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-multiple-refer-03</draft>
        <updated-by>
            <doc-id>RFC8262</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5368</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5369</doc-id>
        <title>Framework for Transcoding with the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>transcoding services</kw>
            <kw>conference bridge model</kw>
            <kw>third-party call control model</kw>
            <kw>deaf</kw>
            <kw>hard of hearing</kw>
            <kw>speech-impaired</kw>
        </keywords>
        <abstract><p>This document defines a framework for transcoding with SIP.  This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services.  Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model.  Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-transc-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5370</doc-id>
        <title>The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>transcoding service</kw>
            <kw>deaf</kw>
            <kw>hard of hearing</kw>
            <kw>speech-impaired</kw>
        </keywords>
        <abstract><p>This document describes how to invoke transcoding services using the conference bridge model.  This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-transc-conf-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5370</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5371</doc-id>
        <title>RTP Payload Format for JPEG 2000 Video Streams</title>
        <author>
            <name>S. Futemma</name>
        </author>
        <author>
            <name>E. Itakura</name>
        </author>
        <author>
            <name>A. Leung</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>JPEG 2000 video</kw>
            <kw>RTP</kw>
            <kw>Real-time Transport Protocol</kw>
            <kw>main header</kw>
            <kw>tile number</kw>
            <kw>Sony Corporation</kw>
        </keywords>
        <abstract><p>This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec.  T.800, better known as JPEG 2000.  JPEG 2000 features are considered in the design of this payload format.  JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways.  The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-jpeg2000-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5371</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5372</doc-id>
        <title>Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery</title>
        <author>
            <name>A. Leung</name>
        </author>
        <author>
            <name>S. Futemma</name>
        </author>
        <author>
            <name>E. Itakura</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Real-time Transport Protocol</kw>
            <kw>main header compensation</kw>
            <kw>priority field</kw>
            <kw>priority mapping table</kw>
            <kw>packet-number-based ordering</kw>
            <kw>progression-based ordering</kw>
            <kw>layer-based ordering</kw>
            <kw>resolution-based ordering</kw>
            <kw>component-based ordering</kw>
            <kw>Sony Corporation</kw>
        </keywords>
        <abstract><p>This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.</p><p> This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-jpeg2000-beam-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5373</doc-id>
        <title>Requesting Answering Modes for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>D. Willis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Allen</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>PoC</kw>
            <kw>PTT</kw>
            <kw>auto</kw>
            <kw>automatic</kw>
            <kw>manual</kw>
            <kw>answer</kw>
            <kw>loopback</kw>
            <kw>diagnostic</kw>
            <kw>answer-mode</kw>
            <kw>priv-answer-mode</kw>
        </keywords>
        <abstract><p>This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request.  The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input.  The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements.  These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back.  Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-answermode-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5373</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5374</doc-id>
        <title>Multicast Extensions to the Security Architecture for the Internet Protocol</title>
        <author>
            <name>B. Weis</name>
        </author>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>D. Ignjatic</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>ip</kw>
            <kw>ipsec</kw>
            <kw>ip multicast packets</kw>
        </keywords>
        <abstract><p>The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer.  That architecture primarily defines services for Internet Protocol (IP) unicast packets.  This document describes how the IPsec security services are applied to IP multicast packets.  These extensions are relevant only for an IPsec implementation that supports multicast. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-ipsec-extensions-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC5374</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5375</doc-id>
        <title>IPv6 Unicast Address Assignment Considerations</title>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>C. Popoviciu</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>O. Bonness</name>
        </author>
        <author>
            <name>C. Hahn</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>internet protocol version 6</kw>
            <kw>address architecture</kw>
        </keywords>
        <abstract><p>One fundamental aspect of any IP communications infrastructure is its addressing plan.  With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing.  Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6.  This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments.  The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-v6ops-addcon-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5375</errata-url>
        <doi>10.17487/RFC5375</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5376</doc-id>
        <title>Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)</title>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>PCECP</kw>
            <kw>inter-AS PCE</kw>
            <kw>inter-provider PCE</kw>
            <kw>inter-AS MPLS-TE</kw>
            <kw>inter-provider MPLS-TE</kw>
            <kw>inter-AS PCECP</kw>
            <kw>inter-provider PCECP</kw>
            <kw>GMPLS path computation</kw>
            <kw>MPLS-TE path computation</kw>
            <kw>path computation element</kw>
            <kw>path computation communication protocol</kw>
            <kw>path computing element</kw>
            <kw>Interas</kw>
            <kw>Interas TE</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.</p><p> The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-interas-pcecp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC5376</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5377</doc-id>
        <title>Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents</title>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>contributors</kw>
            <kw>ietf contributions</kw>
            <kw>outbound rights</kw>
        </keywords>
        <abstract><p>Contributors grant intellectual property rights to the IETF.  The IETF Trust holds and manages those rights on behalf of the IETF.  The Trustees of the IETF Trust are responsible for that management.  This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs.  The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted.  This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipr-outbound-rights-07</draft>
        <obsoleted-by>
            <doc-id>RFC8721</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5377</errata-url>
        <doi>10.17487/RFC5377</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5378</doc-id>
        <title>Rights Contributors Provide to the IETF Trust</title>
        <author>
            <name>S. Bradner</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Contreras</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>intellectual property rights</kw>
            <kw>copyright</kw>
            <kw>ipr</kw>
        </keywords>
        <abstract><p>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 obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, 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.</p></abstract>
        <draft>draft-ietf-ipr-3978-incoming-09</draft>
        <obsoletes>
            <doc-id>RFC3978</doc-id>
            <doc-id>RFC4748</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>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ipr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5378</errata-url>
        <doi>10.17487/RFC5378</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5379</doc-id>
        <title>Guidelines for Using the Privacy Mechanism for SIP</title>
        <author>
            <name>M. Munakata</name>
        </author>
        <author>
            <name>S. Schubert</name>
        </author>
        <author>
            <name>T. Ohba</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Privacy</kw>
            <kw>priv-value</kw>
            <kw>guideline</kw>
        </keywords>
        <abstract><p>This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244.  It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-munakata-sip-privacy-guideline-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5379</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5380</doc-id>
        <title>Hierarchical Mobile IPv6 (HMIPv6) Mobility Management</title>
        <author>
            <name>H. Soliman</name>
        </author>
        <author>
            <name>C. Castelluccia</name>
        </author>
        <author>
            <name>K. ElMalki</name>
        </author>
        <author>
            <name>L. Bellier</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>mobile ipv6</kw>
            <kw>ipv6 neighbor discovery</kw>
            <kw>map</kw>
            <kw>mobility anchor point</kw>
        </keywords>
        <abstract><p>This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling.  Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent.  The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-4140bis-05</draft>
        <obsoletes>
            <doc-id>RFC4140</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5380</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5381</doc-id>
        <title>Experience of Implementing NETCONF over SOAP</title>
        <author>
            <name>T. Iijima</name>
        </author>
        <author>
            <name>Y. Atarashi</name>
        </author>
        <author>
            <name>H. Kimura</name>
        </author>
        <author>
            <name>M. Kitani</name>
        </author>
        <author>
            <name>H. Okita</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>simple object access protocol</kw>
            <kw>network configuration protocol</kw>
            <kw>mns</kw>
            <kw>network management system</kw>
        </keywords>
        <abstract><p>This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server.  It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP.  When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available.  By making full use of these tools, developers can significantly reduce their workload.  The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP.  This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iijima-netconf-soap-implementation-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5381</errata-url>
        <doi>10.17487/RFC5381</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5382</doc-id>
        <title>NAT Behavioral Requirements for TCP</title>
        <author>
            <name>S. Guha</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Biswas</name>
        </author>
        <author>
            <name>B. Ford</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>network address translation</kw>
        </keywords>
        <abstract><p>This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently.  Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-behave-tcp-08</draft>
        <updated-by>
            <doc-id>RFC7857</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0142</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC5382</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5383</doc-id>
        <title>Deployment Considerations for Lemonade-Compliant Mobile Email</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-lemonade-deployments-09</draft>
        <is-also>
            <doc-id>BCP0143</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5383</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5384</doc-id>
        <title>The Protocol Independent Multicast (PIM) Join Attribute Format</title>
        <author>
            <name>A. Boers</name>
        </author>
        <author>
            <name>I. Wijnands</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>pim-sm</kw>
            <kw>multicast distribution tree</kw>
            <kw>pim join attribute</kw>
            <kw>attr_type</kw>
        </keywords>
        <abstract><p>A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join.  Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card").  Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree.  However, there has been no way to do so until now.  This document describes a modification of the Join message that allows a node to associate attributes with a particular tree.  The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-join-attributes-06</draft>
        <updated-by>
            <doc-id>RFC7887</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5384</errata-url>
        <doi>10.17487/RFC5384</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5385</doc-id>
        <title>Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>writing I-Ds</kw>
            <kw>writing RFCs</kw>
            <kw>authoring</kw>
            <kw> tools</kw>
            <kw>document preparation</kw>
        </keywords>
        <abstract><p>This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.</p><p> The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-touch-msword-template-v2.0-07</draft>
        <obsoletes>
            <doc-id>RFC3285</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5385</errata-url>
        <doi>10.17487/RFC5385</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5386</doc-id>
        <title>Better-Than-Nothing Security: An Unauthenticated Mode of IPsec</title>
        <author>
            <name>N. Williams</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet protocol security</kw>
            <kw>ikev1</kw>
            <kw>ikev2</kw>
            <kw>sas</kw>
            <kw>esp</kw>
            <kw>ah</kw>
            <kw>pad</kw>
            <kw>spd</kw>
            <kw>btns</kw>
            <kw>unauthenticated ipsec</kw>
        </keywords>
        <abstract><p>This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH).  No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified.  Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-btns-core-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>btns</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5386</errata-url>
        <doi>10.17487/RFC5386</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5387</doc-id>
        <title>Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>Y. Wang</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>ipsec</kw>
            <kw>stand-alone btns</kw>
            <kw>sab</kw>
            <kw>channel-bound btns</kw>
            <kw>cbb</kw>
        </keywords>
        <abstract><p>The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.</p><p> This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-btns-prob-and-applic-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>btns</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5387</errata-url>
        <doi>10.17487/RFC5387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5388</doc-id>
        <title>Information Model and XML Data Model for Traceroute Measurements</title>
        <author>
            <name>S. Niccolini</name>
        </author>
        <author>
            <name>S. Tartarelli</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>T. Dietz</name>
        </author>
        <author>
            <name>M. Swany</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>DISMAN-TRACEROUTE-MIB</kw>
        </keywords>
        <abstract><p>This document describes a standard way to store the configuration and the results of traceroute measurements.  This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements).  Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier.  On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-storetraceroutes-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC5388</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5389</doc-id>
        <title>Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>October</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>SIPs</kw>
            <kw>NAT</kw>
            <kw>STUN</kw>
            <kw>Traversal</kw>
            <kw>ICE</kw>
            <kw>firewall</kw>
            <kw>TURN</kw>
            <kw>VOIP</kw>
        </keywords>
        <abstract><p>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.</p><p> STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.</p><p> This document obsoletes RFC 3489. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-rfc3489bis-18</draft>
        <obsoletes>
            <doc-id>RFC3489</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8489</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7350</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5389</errata-url>
        <doi>10.17487/RFC5389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5390</doc-id>
        <title>Requirements for Management of Overload in the Session Initiation Protocol</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>overload handling</kw>
            <kw>503 response</kw>
        </keywords>
        <abstract><p>Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request.  SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded.  However, numerous problems have been identified with this mechanism.  This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sipping-overload-reqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5390</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5391</doc-id>
        <title>RTP Payload Format for ITU-T Recommendation G.711.1</title>
        <author>
            <name>A. Sollaud</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>itu telecommunication standardization sector</kw>
            <kw>audio coded</kw>
            <kw>pcmu-wb</kw>
            <kw>pcma-wb</kw>
        </keywords>
        <abstract><p>This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec.  Two media type registrations are also included. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-g711wb-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5391</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5392</doc-id>
        <title>OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>X. Duan</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>generalized mpls</kw>
            <kw>gmpls-te</kw>
            <kw>mpls-te</kw>
            <kw>isis-te</kw>
            <kw>open shortest path first</kw>
            <kw>ospf-te</kw>
        </keywords>
        <abstract><p>This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.</p><p> No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-ospf-interas-te-extension-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5392</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5393</doc-id>
        <title>Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies</title>
        <author>
            <name>R. Sparks</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Lawrence</name>
        </author>
        <author>
            <name>A. Hawrylyshen</name>
        </author>
        <author>
            <name>B. Campen</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <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><p>This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.</p><p> This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-fork-loop-fix-08</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5393</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5394</doc-id>
        <title>Policy-Enabled Path Computation Framework</title>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>J. Ash</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>pce policy</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation.  This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy.  This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy.  This document also provides representative scenarios for the support of PCE Policy.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-policy-enabled-path-comp-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC5394</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5395</doc-id>
        <title>Domain Name System (DNS) IANA Considerations</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RRTYPE</kw>
            <kw>RCODE</kw>
            <kw>AFSDB</kw>
        </keywords>
        <abstract><p>Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-dnsext-2929bis-07</draft>
        <obsoletes>
            <doc-id>RFC2929</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6195</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1183</doc-id>
            <doc-id>RFC3597</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5395</errata-url>
        <doi>10.17487/RFC5395</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5396</doc-id>
        <title>Textual Representation of Autonomous System (AS) Numbers</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>decimal value</kw>
        </keywords>
        <abstract><p>A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number.  This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-as-representation-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC5396</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5397</doc-id>
        <title>WebDAV Current Principal Extension</title>
        <author>
            <name>W. Sanchez</name>
        </author>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>http</kw>
            <kw>webdav</kw>
            <kw>access control</kw>
            <kw>acl</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-sanchez-webdav-current-principal-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5397</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5398</doc-id>
        <title>Autonomous System (AS) Number Reservation for Documentation Use</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>autonomous system numbers</kw>
            <kw>asn</kw>
        </keywords>
        <abstract><p>To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like.  This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-idr-as-documentation-reservation-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC5398</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5399</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5400</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5401</doc-id>
        <title>Multicast Negative-Acknowledgment (NACK) 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>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback.  The rationale for protocol design goals and assumptions are presented.  Technical challenges for NACK-based (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 reliable multicast protocol operation.  It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.  This document obsoletes RFC 3941. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-norm-revised-07</draft>
        <obsoletes>
            <doc-id>RFC3941</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC5401</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5402</doc-id>
        <title>Compressed Data within an Internet Electronic Data Interchange (EDI) Message</title>
        <author>
            <name>T. Harding</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>internet edi</kw>
        </keywords>
        <abstract><p>This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ediint-compression-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5402</errata-url>
        <doi>10.17487/RFC5402</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5403</doc-id>
        <title>RPCSEC_GSS Version 2</title>
        <author>
            <name>M. Eisler</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Kerberos</kw>
            <kw>ONC</kw>
            <kw>RPC</kw>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>integrity</kw>
            <kw>GSS</kw>
            <kw>GSS-API</kw>
            <kw>privacy</kw>
            <kw>confidentiality</kw>
            <kw>encryption</kw>
            <kw>MIC</kw>
            <kw>NFS</kw>
            <kw>credential</kw>
            <kw>verifier</kw>
            <kw>mechanism</kw>
            <kw>context</kw>
        </keywords>
        <abstract><p>This document describes version 2 of the RPCSEC_GSS protocol.  Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added.  RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-rpcsec-gss-v2-06</draft>
        <updates>
            <doc-id>RFC2203</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7861</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC5403</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5404</doc-id>
        <title>RTP Payload Format for G.719</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>I. Johansson</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>ITU-T</kw>
            <kw>g.719 full-band codec</kw>
        </keywords>
        <abstract><p>This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP).  The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-g719-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5404</errata-url>
        <doi>10.17487/RFC5404</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5405</doc-id>
        <title>Unicast UDP Usage Guidelines for Application Designers</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>November</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>user datagram protocol</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.  Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic.  This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-tsvwg-udp-guidelines-11</draft>
        <obsoleted-by>
            <doc-id>RFC8085</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5405</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5406</doc-id>
        <title>Guidelines for Specifying the Use of IPsec Version 2</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>internet security</kw>
            <kw>security considerations</kw>
        </keywords>
        <abstract><p>The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec".  While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms.  This memo offers some guidance on when IPsec Version 2 should and should not be specified.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-bellovin-useipsec-10</draft>
        <is-also>
            <doc-id>BCP0146</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5406</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5407</doc-id>
        <title>Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>M. Hasebe</name>
        </author>
        <author>
            <name>J. Koshiko</name>
        </author>
        <author>
            <name>Y. Suzuki</name>
        </author>
        <author>
            <name>T. Yoshikawa</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>December</month>
            <year>2008</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>sip user agents</kw>
            <kw>sip ua</kw>
            <kw>sip proxy servers</kw>
        </keywords>
        <abstract><p>This document gives example call flows of race conditions in the Session Initiation Protocol (SIP).  Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them.  The elements in these call flows include SIP User Agents and SIP Proxy Servers.  Call flow diagrams and message details are given.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-sipping-race-examples-06</draft>
        <is-also>
            <doc-id>BCP0147</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5407</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5408</doc-id>
        <title>Identity-Based Encryption Architecture and Supporting Data Structures</title>
        <author>
            <name>G. Appenzeller</name>
        </author>
        <author>
            <name>L. Martin</name>
        </author>
        <author>
            <name>M. Schertler</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>public key</kw>
            <kw>public-key encryption technology</kw>
        </keywords>
        <abstract><p>This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key.  It also defines data structures that can be used to implement the technology.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-smime-ibearch-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5408</errata-url>
        <doi>10.17487/RFC5408</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5409</doc-id>
        <title>Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>L. Martin</name>
        </author>
        <author>
            <name>M. Schertler</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>bf</kw>
            <kw>bbq</kw>
            <kw>content-encryption keys</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys.  Object identifiers and the convention for encoding a recipient's identity are also defined.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-smime-bfibecms-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC5409</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5410</doc-id>
        <title>Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0</title>
        <author>
            <name>A. Jerichow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Piron</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>MIKEY Extension</kw>
            <kw>IANA registration</kw>
            <kw>OMA BCAST</kw>
        </keywords>
        <abstract><p>This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload to transport the short-term key message (STKM) and long-term key message (LTKM) payloads as well as the management data LTKM reporting message and parental control message payloads defined in the Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service and Content protection specification.</p></abstract>
        <draft>draft-jerichow-msec-mikey-genext-oma-00</draft>
        <obsoletes>
            <doc-id>RFC4909</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6309</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5410</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5411</doc-id>
        <title>A Hitchhiker's Guide to the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>42</kw>
            <kw>don't panic</kw>
            <kw>sip overview,</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF.  It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP.  This specification serves as a guide to the SIP RFC series.  It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sip-hitchhikers-guide-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5412</doc-id>
        <title>Lightweight Access Point Protocol</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>R. Suri</name>
        </author>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>M. Williams</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>B. O'Hara</name>
        </author>
        <author>
            <name>S. Kelly</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>125</page-count>
        <keywords>
            <kw>lwapp</kw>
            <kw>capwap</kw>
        </keywords>
        <abstract><p>In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.</p><p> The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-ohara-capwap-lwapp-04</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5412</errata-url>
        <doi>10.17487/RFC5412</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5413</doc-id>
        <title>SLAPP: Secure Light Access Point Protocol</title>
        <author>
            <name>P. Narasimhan</name>
        </author>
        <author>
            <name>D. Harkins</name>
        </author>
        <author>
            <name>S. Ponnuswamy</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>capwap</kw>
        </keywords>
        <abstract><p>The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.</p><p> In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.</p><p> Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-narasimhan-ietf-slapp-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5413</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5414</doc-id>
        <title>Wireless LAN Control Protocol (WiCoP)</title>
        <author>
            <name>S. Iino</name>
        </author>
        <author>
            <name>S. Govindan</name>
        </author>
        <author>
            <name>M. Sugiura</name>
        </author>
        <author>
            <name>H. Cheng</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>wlan</kw>
            <kw>wireless local area network</kw>
            <kw>twp</kw>
            <kw>wireless termination points</kw>
            <kw>capwap</kw>
            <kw>control and provisioning of wireless access points</kw>
        </keywords>
        <abstract><p>The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common.</p><p> The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-iino-capwap-wicop-02</draft>
        <obsoleted-by>
            <doc-id>RFC5415</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5414</errata-url>
        <doi>10.17487/RFC5414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5415</doc-id>
        <title>Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification</title>
        <author>
            <name>P. Calhoun</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Montemurro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Stanley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>155</page-count>
        <keywords>
            <kw>LWAPP</kw>
            <kw>CAPWAP</kw>
            <kw>802.11</kw>
            <kw>IEEE</kw>
            <kw>Wireless LAN</kw>
            <kw>WiFi</kw>
            <kw>Access Point</kw>
            <kw>Access Controller</kw>
            <kw>Wireless Termination Point</kw>
        </keywords>
        <abstract><p>This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564.  The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies.  This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-capwap-protocol-specification-15</draft>
        <obsoletes>
            <doc-id>RFC5414</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8553</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5415</errata-url>
        <doi>10.17487/RFC5415</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5416</doc-id>
        <title>Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11</title>
        <author>
            <name>P. Calhoun</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Montemurro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Stanley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>Operations and Management</kw>
            <kw>LWAPP</kw>
            <kw>CAPWAP</kw>
            <kw>802.11</kw>
            <kw>IEEE</kw>
            <kw>Wireless LAN</kw>
            <kw>WiFi</kw>
            <kw>Access Point</kw>
            <kw>Access Controller</kw>
            <kw>Wireless Termination Point</kw>
        </keywords>
        <abstract><p>Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.</p><p> This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-capwap-protocol-binding-ieee80211-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5416</errata-url>
        <doi>10.17487/RFC5416</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5417</doc-id>
        <title>Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>CAPWAP</kw>
            <kw>802.11</kw>
            <kw>IEEE</kw>
            <kw>Wireless LAN</kw>
            <kw>WiFi</kw>
            <kw>Access Point</kw>
            <kw>Access Controller</kw>
            <kw>Wireless Termination Point</kw>
        </keywords>
        <abstract><p>The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect.  This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-capwap-dhc-ac-option-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC5417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5418</doc-id>
        <title>Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments</title>
        <author>
            <name>S. Kelly</name>
        </author>
        <author>
            <name>T. Clancy</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>WLAN</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a \%stand-alone interface between the wired and wireless network segments.  However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues.  CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops.  This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-capwap-threat-analysis-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC5418</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5419</doc-id>
        <title>Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)</title>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>authentication signaling message</kw>
            <kw>mn</kw>
            <kw>ha</kw>
        </keywords>
        <abstract><p>Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA).  These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA.  The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding.  This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mip6-whyauthdataoption-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC5419</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5420</doc-id>
        <title>Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>A. Ayyangar</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>label switched paths</kw>
            <kw>SESSION_ATTRIBUTE</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.</p><p> This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.</p><p> The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.</p><p> This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rfc4420bis-03</draft>
        <obsoletes>
            <doc-id>RFC4420</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6510</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5420</errata-url>
        <doi>10.17487/RFC5420</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5421</doc-id>
        <title>Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)</title>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>H. Zhou</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>generic token card</kw>
            <kw>eap-gtc</kw>
        </keywords>
        <abstract><p>The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-zhou-emu-fast-gtc-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5421</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5422</doc-id>
        <title>Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)</title>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>H. Zhou</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  EAP- FAST also enables the provisioning credentials or other information through this protected tunnel.  This document describes the use of EAP-FAST for dynamic provisioning.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-cam-winget-eap-fast-provisioning-10</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5422</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5423</doc-id>
        <title>Internet Message Store Events</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>imap</kw>
        </keywords>
        <abstract><p>One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.</p><p> This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-msgevent-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5423</errata-url>
        <doi>10.17487/RFC5423</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5424</doc-id>
        <title>The Syslog Protocol</title>
        <author>
            <name>R. Gerhards</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>event notification message</kw>
            <kw>syslog message</kw>
            <kw>berkeley</kw>
            <kw>software</kw>
            <kw>distribution</kw>
            <kw>transmission</kw>
            <kw>messages</kw>
        </keywords>
        <abstract><p>This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.</p><p> This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-syslog-protocol-23</draft>
        <obsoletes>
            <doc-id>RFC3164</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5424</errata-url>
        <doi>10.17487/RFC5424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5425</doc-id>
        <title>Transport Layer Security (TLS) Transport Mapping for Syslog</title>
        <author>
            <name>F. Miao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ma</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Salowey</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>syslog message</kw>
            <kw>syslog security</kw>
        </keywords>
        <abstract><p>This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages.  This document describes the security threats to syslog and how TLS can be used to counter such threats.</p></abstract>
        <draft>draft-ietf-syslog-transport-tls-14</draft>
        <updated-by>
            <doc-id>RFC9662</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5425</errata-url>
        <doi>10.17487/RFC5425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5426</doc-id>
        <title>Transmission of Syslog Messages over UDP</title>
        <author>
            <name>A. Okmianski</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>udp</kw>
            <kw>User Datagram Protocol</kw>
        </keywords>
        <abstract><p>This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6.  The syslog protocol layered architecture provides for support of any number of transport mappings.  However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-syslog-transport-udp-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <doi>10.17487/RFC5426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5427</doc-id>
        <title>Textual Conventions for Syslog Management</title>
        <author>
            <name>G. Keeni</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>syslog facility</kw>
            <kw>syslog severity</kw>
            <kw>MIB</kw>
            <kw>textual-convention</kw>
        </keywords>
        <abstract><p>This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages.  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-syslog-tc-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <doi>10.17487/RFC5427</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5428</doc-id>
        <title>Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices</title>
        <author>
            <name>S. Channabasappa</name>
        </author>
        <author>
            <name>W. De Ketelaere</name>
        </author>
        <author>
            <name>E. Nechamkin</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>multimedia terminal adapter</kw>
            <kw>PKTC-IETF-EVENT-MIB</kw>
        </keywords>
        <abstract><p>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 Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipcdn-pktc-eventmess-14</draft>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipcdn</wg_acronym>
        <doi>10.17487/RFC5428</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5429</doc-id>
        <title>Sieve Email Filtering: Reject and Extended Reject Extensions</title>
        <author>
            <name>A. Stone</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>sieve</kw>
            <kw>refuse</kw>
            <kw>reject</kw>
            <kw>ereject</kw>
            <kw>joe-job</kw>
            <kw>smtp</kw>
            <kw>lmtp</kw>
            <kw>spam</kw>
        </keywords>
        <abstract><p>This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.</p><p> A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.</p><p> This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible.</p><p> The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-refuse-reject-09</draft>
        <obsoletes>
            <doc-id>RFC3028</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5228</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5429</errata-url>
        <doi>10.17487/RFC5429</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5430</doc-id>
        <title>Suite B Profile for Transport Layer Security (TLS)</title>
        <author>
            <name>M. Salter</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>nsa suite b cryptography</kw>
        </keywords>
        <abstract><p>The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications.  This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully conformant with Suite B.  This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-rescorla-tls-suiteb-11</draft>
        <obsoleted-by>
            <doc-id>RFC6460</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5430</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5431</doc-id>
        <title>Diameter ITU-T Rw Policy Enforcement Interface Application</title>
        <author>
            <name>D. Sun</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>diameter command code</kw>
            <kw>itu-t</kw>
            <kw>ITU-T Rw</kw>
            <kw>Policy-Install-Request</kw>
            <kw>pir</kw>
            <kw>Policy-Install-Answer</kw>
            <kw>pia</kw>
        </keywords>
        <abstract><p>This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec.  Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-sun-dime-itu-t-rw-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5432</doc-id>
        <title>Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)</title>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>S. Dhesikan</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>offer/answer</kw>
            <kw>media stream</kw>
        </keywords>
        <abstract><p>The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish.  Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use.  However, on the Internet, there is more than one QoS service available.  Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream.  This document defines such a mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-qos-identification-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC5432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5433</doc-id>
        <title>Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method</title>
        <author>
            <name>T. Clancy</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>EAP-GPSK</kw>
            <kw>pre-shared key</kw>
        </keywords>
        <abstract><p>This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK).  This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-emu-eap-gpsk-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC5433</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5434</doc-id>
        <title>Considerations for Having a Successful Birds-of-a-Feather (BOF) Session</title>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ietf bof</kw>
            <kw>working group</kw>
        </keywords>
        <abstract><p>This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group.  It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-narten-successful-bof-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5434</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5435</doc-id>
        <title>Sieve Email Filtering: Extension for Notifications</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Leiba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Segmuller</name>
        </author>
        <author>
            <name>T. Martin</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
        </keywords>
        <abstract><p>Users go to great lengths to be notified as quickly as possible that they have received new mail.  Most of these methods involve polling to check for new messages periodically.  A push method handled by the final delivery agent gives users quicker notifications and saves server resources.  This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular.  This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-notify-12</draft>
        <updated-by>
            <doc-id>RFC8580</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5435</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5436</doc-id>
        <title>Sieve Notification Mechanism: mailto</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>M. Haardt</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>eletctronic mail notification</kw>
        </keywords>
        <abstract><p>This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-notify-mailto-10</draft>
        <updates>
            <doc-id>RFC3834</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5436</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5437</doc-id>
        <title>Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>jabber</kw>
        </keywords>
        <abstract><p>This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-notify-xmpp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5437</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5438</doc-id>
        <title>Instant Message Disposition Notification (IMDN)</title>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>H. Khartabil</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>im</kw>
            <kw>instant messaging</kw>
            <kw>cpim</kw>
            <kw>common presence and instant messaging</kw>
        </keywords>
        <abstract><p>Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.</p><p> The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.</p><p> This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-imdn-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5438</errata-url>
        <doi>10.17487/RFC5438</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5439</doc-id>
        <title>An Analysis of Scaling Issues in MPLS-TE Core Networks</title>
        <author>
            <name>S. Yasukawa</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>O. Komolafe</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>traffic engineered</kw>
            <kw>scaling concerns</kw>
            <kw>lsp</kw>
            <kw>label switch path</kw>
            <kw> point-to-point mpls-te lsps</kw>
        </keywords>
        <abstract><p>Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.</p><p> This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.</p><p> This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-te-scaling-analysis-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5439</errata-url>
        <doi>10.17487/RFC5439</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5440</doc-id>
        <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JL. Le Roux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>87</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>GMPLS</kw>
            <kw>Traffic Engineering</kw>
            <kw>Label Switched Path</kw>
        </keywords>
        <abstract><p>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs.  Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering.  PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-pcep-19</draft>
        <updated-by>
            <doc-id>RFC7896</doc-id>
            <doc-id>RFC8253</doc-id>
            <doc-id>RFC8356</doc-id>
            <doc-id>RFC9488</doc-id>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5440</errata-url>
        <doi>10.17487/RFC5440</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5441</doc-id>
        <title>A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>te lsp</kw>
            <kw>path computation element</kw>
        </keywords>
        <abstract><p>The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement.  In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems.  This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique.  This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-brpc-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5441</errata-url>
        <doi>10.17487/RFC5441</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5442</doc-id>
        <title>LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail</title>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>enhancements to internet email to supportt diverse service environments</kw>
            <kw>Phone</kw>
        </keywords>
        <abstract><p>This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols.  This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF.  This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-lemonade-architecture-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5442</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5443</doc-id>
        <title>LDP IGP Synchronization</title>
        <author>
            <name>M. Jork</name>
        </author>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>label distribution protocol</kw>
            <kw>interior gateway protocol</kw>
        </keywords>
        <abstract><p>In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications.  For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately.  Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not.  While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores.  This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-ldp-igp-sync-04</draft>
        <updated-by>
            <doc-id>RFC6138</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5443</errata-url>
        <doi>10.17487/RFC5443</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5444</doc-id>
        <title>Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>J. Dean</name>
        </author>
        <author>
            <name>C. Adjih</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>TLV</kw>
            <kw>address</kw>
        </keywords>
        <abstract><p>This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-manet-packetbb-17</draft>
        <updated-by>
            <doc-id>RFC7631</doc-id>
            <doc-id>RFC8245</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5444</errata-url>
        <doi>10.17487/RFC5444</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5445</doc-id>
        <title>Basic Forward Error Correction (FEC) Schemes</title>
        <author>
            <name>M. Watson</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme.  This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-basic-schemes-revised-06</draft>
        <obsoletes>
            <doc-id>RFC3452</doc-id>
            <doc-id>RFC3695</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5445</errata-url>
        <doi>10.17487/RFC5445</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5446</doc-id>
        <title>Service Selection for Mobile IPv4</title>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>U. Nilsson</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet protocol version 4</kw>
            <kw>host name agent</kw>
            <kw>mobility service subscription</kw>
        </keywords>
        <abstract><p>In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node.  The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription.  This document describes a Service Selection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-korhonen-mip4-service-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5446</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5447</doc-id>
        <title>Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Bournelle</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>Mobile IPv6</kw>
            <kw>Integrated Scenario</kw>
        </keywords>
        <abstract><p>A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6.  RFC 3775 requires that some or all of these parameters be statically configured.  Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node.  An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures.  This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-mip6-integrated-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5447</errata-url>
        <doi>10.17487/RFC5447</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5448</doc-id>
        <title>Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>V. Lehtovirta</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>AKA</kw>
            <kw>AKA'</kw>
            <kw>3GPP</kw>
        </keywords>
        <abstract><p>This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.</p><p> This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-arkko-eap-aka-kdf-10</draft>
        <updates>
            <doc-id>RFC4187</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9048</doc-id>
            <doc-id>RFC9678</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5448</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5449</doc-id>
        <title>OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks</title>
        <author>
            <name>E. Baccelli</name>
        </author>
        <author>
            <name>P. Jacquet</name>
        </author>
        <author>
            <name>D. Nguyen</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>interface type</kw>
            <kw>mobile ad hoc</kw>
        </keywords>
        <abstract><p>This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks.  This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type".  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ospf-manet-mpr-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5449</errata-url>
        <doi>10.17487/RFC5449</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5450</doc-id>
        <title>Transmission Time Offsets in RTP Streams</title>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>H. Desineni</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>real-time transport</kw>
            <kw>IJ</kw>
            <kw>inter-arrival jitter</kw>
        </keywords>
        <abstract><p>This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time.  It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-toffset-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5450</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5451</doc-id>
        <title>Message Header Field for Indicating Message Authentication Status</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>authentication-results</kw>
            <kw>email authentication result</kw>
        </keywords>
        <abstract><p>This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kucherawy-sender-auth-header-20</draft>
        <obsoleted-by>
            <doc-id>RFC7001</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6577</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5451</errata-url>
        <doi>10.17487/RFC5451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5452</doc-id>
        <title>Measures for Making DNS More Resilient against Forged Answers</title>
        <author>
            <name>A. Hubert</name>
        </author>
        <author>
            <name>R. van Mook</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>spoofing</kw>
            <kw>source port</kw>
            <kw>hardening</kw>
        </keywords>
        <abstract><p>The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.</p><p> Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.</p><p> By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-forgery-resilience-10</draft>
        <updates>
            <doc-id>RFC2181</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5452</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5453</doc-id>
        <title>Reserved IPv6 Interface Identifiers</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>unicast address</kw>
        </keywords>
        <abstract><p>Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link.  They are required to be unique within a subnet.  Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them.  An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences.  Since there is no centralized repository for such reserved identifiers, this document aims to create one. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-reserved-iids-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5453</errata-url>
        <doi>10.17487/RFC5453</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5454</doc-id>
        <title>Dual-Stack Mobile IPv4</title>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>V. Park</name>
        </author>
        <author>
            <name>H. Soliman</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>mipv4</kw>
        </keywords>
        <abstract><p>This specification provides IPv6 extensions to the Mobile IPv4 protocol.  The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-dsmipv4-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5454</errata-url>
        <doi>10.17487/RFC5454</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5455</doc-id>
        <title>Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol</title>
        <author>
            <name>S. Sivabalan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Parker</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>classtype</kw>
            <kw>ds-te</kw>
            <kw>diffserv-aware traffic engineering</kw>
            <kw>pce</kw>
        </keywords>
        <abstract><p>This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-dste-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5455</errata-url>
        <doi>10.17487/RFC5455</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5456</doc-id>
        <title>IAX: Inter-Asterisk eXchange Version 2</title>
        <author>
            <name>M. Spencer</name>
        </author>
        <author>
            <name>B. Capouch</name>
        </author>
        <author>
            <name>E. Guy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Miller</name>
        </author>
        <author>
            <name>K. Shumard</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>asterisk private branch exchange</kw>
            <kw>pbx</kw>
            <kw>voip</kw>
            <kw>voice over internet protocol</kw>
        </keywords>
        <abstract><p>This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.</p><p> IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-guy-iax-05</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5457</doc-id>
        <title>IANA Considerations for IAX: Inter-Asterisk eXchange Version 2</title>
        <author>
            <name>E. Guy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>asterisk private branch exchange</kw>
            <kw>pbx</kw>
            <kw>voip</kw>
            <kw>voice over internet protocol</kw>
        </keywords>
        <abstract><p>This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks.  IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-guy-iaxiana-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5457</errata-url>
        <doi>10.17487/RFC5457</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5458</doc-id>
        <title>Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol</title>
        <author>
            <name>H. Cruickshank</name>
        </author>
        <author>
            <name>P. Pillai</name>
        </author>
        <author>
            <name>M. Noisternig</name>
        </author>
        <author>
            <name>S. Iyengar</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>iso 13818-1</kw>
            <kw>transport stream</kw>
            <kw>ts</kw>
            <kw>ule stream</kw>
            <kw>gse</kw>
            <kw>generic stream encapsulation</kw>
        </keywords>
        <abstract><p>The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.</p><p> The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipdvb-sec-req-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipdvb</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5458</errata-url>
        <doi>10.17487/RFC5458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5459</doc-id>
        <title>G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support</title>
        <author>
            <name>A. Sollaud</name>
        </author>
        <date>
            <month>January</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>rtp</kw>
            <kw>itu-t</kw>
            <kw>international telecommunication union</kw>
            <kw>g.729.1</kw>
            <kw>audio codec</kw>
        </keywords>
        <abstract><p>This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec.  It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way.  An updated media type registration is included for this payload format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc4749-dtx-update-03</draft>
        <updates>
            <doc-id>RFC4749</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5460</doc-id>
        <title>DHCPv6 Bulk Leasequery</title>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>dynamic hos configuration protocol</kw>
            <kw>ipv6</kw>
            <kw>dhcpv6 bindings</kw>
        </keywords>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings.  That mechanism is limited to queries for individual bindings.  In some situations individual binding queries may not be efficient, or even possible.  This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-bulk-leasequery-06</draft>
        <updated-by>
            <doc-id>RFC7653</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5460</errata-url>
        <doi>10.17487/RFC5460</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5461</doc-id>
        <title>TCP's Reaction to Soft Errors</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>icmp</kw>
            <kw>Internet Control Message Protocol</kw>
        </keywords>
        <abstract><p>This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received.  This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-soft-errors-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC5461</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5462</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>exp</kw>
            <kw>class of service</kw>
            <kw>cos</kw>
            <kw>tc field</kw>
        </keywords>
        <abstract><p>The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".</p><p> Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.</p><p> To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-cosfield-def-08</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
            <doc-id>RFC3270</doc-id>
            <doc-id>RFC3272</doc-id>
            <doc-id>RFC3443</doc-id>
            <doc-id>RFC3469</doc-id>
            <doc-id>RFC3564</doc-id>
            <doc-id>RFC3985</doc-id>
            <doc-id>RFC4182</doc-id>
            <doc-id>RFC4364</doc-id>
            <doc-id>RFC4379</doc-id>
            <doc-id>RFC4448</doc-id>
            <doc-id>RFC4761</doc-id>
            <doc-id>RFC5129</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5462</errata-url>
        <doi>10.17487/RFC5462</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5463</doc-id>
        <title>Sieve Email Filtering:  Ihave Extension</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>ESMTP</kw>
        </keywords>
        <abstract><p>This document describes the "ihave" extension to the Sieve email filtering language.  The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available.  The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-freed-sieve-ihave-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5463</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5464</doc-id>
        <title>The IMAP METADATA Extension</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>internet message access protocol</kw>
            <kw>annotation</kw>
            <kw>metadata</kw>
        </keywords>
        <abstract><p>The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers.  It is possible to have annotations on a per-mailbox basis or on the server as a whole.  For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-daboo-imap-annotatemore-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5464</errata-url>
        <doi>10.17487/RFC5464</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5465</doc-id>
        <title>The IMAP NOTIFY Extension</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <author>
            <name>C. King</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Internet Message Access Protocol</kw>
        </keywords>
        <abstract><p>This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-imap-notify-07</draft>
        <updates>
            <doc-id>RFC5267</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5465</errata-url>
        <doi>10.17487/RFC5465</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5466</doc-id>
        <title>IMAP4 Extension for Named Searches (Filters)</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>C. King</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet Message Access Protocol</kw>
        </keywords>
        <abstract><p>The document defines a way to persistently store named IMAP (RFC 3501) searches on the server.  Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-imapext-filters-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5466</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5467</doc-id>
        <title>GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>A. Takacs</name>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>J. Meuric</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>RSVP-TE</kw>
            <kw>TSPEC</kw>
            <kw>ADSPEC</kw>
        </keywords>
        <abstract><p>This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs).  The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters.  The procedures described in this document are experimental.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-asymm-bw-bidir-lsps-02</draft>
        <obsoleted-by>
            <doc-id>RFC6387</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5467</errata-url>
        <doi>10.17487/RFC5467</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5468</doc-id>
        <title>Performance Analysis of Inter-Domain Path Computation Methodologies</title>
        <author>
            <name>S. Dasgupta</name>
        </author>
        <author>
            <name>J. de Oliveira</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>pce</kw>
            <kw>path computation element</kw>
            <kw>brpc</kw>
            <kw>backward recursive path computation</kw>
        </keywords>
        <abstract><p>This document presents a performance comparison between the per-domain path computation method and the Path Computation Element (PCE) Architecture-based Backward Recursive Path Computation (BRPC) procedure.  Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios.  A performance analysis for each of the path computation methods is then undertaken.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-dasgupta-ccamp-path-comp-analysis-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5468</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5469</doc-id>
        <title>DES and IDEA Cipher Suites for Transport Layer Security (TLS)</title>
        <author>
            <name>P. Eronen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>ciphersuite</kw>
            <kw>data encryption standard</kw>
            <kw>international data encryption algorithm</kw>
        </keywords>
        <abstract><p>Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms.  DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246).  This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tls-des-idea-02</draft>
        <obsoleted-by>
            <doc-id>RFC8996</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC5469</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5470</doc-id>
        <title>Architecture for IP Flow Information Export</title>
        <author>
            <name>G. Sadasivan</name>
        </author>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ipfix</kw>
            <kw>ipfix device</kw>
            <kw>ipfix collector</kw>
        </keywords>
        <abstract><p>This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipfix-architecture-12</draft>
        <updated-by>
            <doc-id>RFC6183</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC5470</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5471</doc-id>
        <title>Guidelines for IP Flow Information Export (IPFIX) Testing</title>
        <author>
            <name>C. Schmoll</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>exporting process</kw>
            <kw>collecting process</kw>
        </keywords>
        <abstract><p>This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes.  This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations.  These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation.  Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipfix-testing-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC5471</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5472</doc-id>
        <title>IP Flow Information Export (IPFIX) Applicability</title>
        <author>
            <name>T. Zseby</name>
        </author>
        <author>
            <name>E. Boschi</name>
        </author>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ie</kw>
            <kw>information element</kw>
            <kw>PSAMP</kw>
            <kw>measurement</kw>
            <kw>QoS monitoring</kw>
            <kw>attack detection</kw>
            <kw>AAA</kw>
            <kw>ipfix framework</kw>
        </keywords>
        <abstract><p>In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications.  We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol.  Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipfix-as-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5472</errata-url>
        <doi>10.17487/RFC5472</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5473</doc-id>
        <title>Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports</title>
        <author>
            <name>E. Boschi</name>
        </author>
        <author>
            <name>L. Mark</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.</p><p> This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ipfix-reducing-redundancy-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5473</errata-url>
        <doi>10.17487/RFC5473</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5474</doc-id>
        <title>A Framework for Packet Selection and Reporting</title>
        <author>
            <name>N. Duffield</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Chiou</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>A. Greenberg</name>
        </author>
        <author>
            <name>M. Grossglauser</name>
        </author>
        <author>
            <name>J. Rexford</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>psamp</kw>
            <kw>selector</kw>
            <kw>collector</kw>
        </keywords>
        <abstract><p>This document specifies a framework for the PSAMP (Packet SAMPling) protocol.  The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector.  This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications.  Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-psamp-framework-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>psamp</wg_acronym>
        <doi>10.17487/RFC5474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5475</doc-id>
        <title>Sampling and Filtering Techniques for IP Packet Selection</title>
        <author>
            <name>T. Zseby</name>
        </author>
        <author>
            <name>M. Molina</name>
        </author>
        <author>
            <name>N. Duffield</name>
        </author>
        <author>
            <name>S. Niccolini</name>
        </author>
        <author>
            <name>F. Raspall</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>psamp</kw>
            <kw>metering process</kw>
        </keywords>
        <abstract><p>This document describes Sampling and Filtering techniques for IP packet selection.  It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes.  Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors.  The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-psamp-sample-tech-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>psamp</wg_acronym>
        <doi>10.17487/RFC5475</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5476</doc-id>
        <title>Packet Sampling (PSAMP) Protocol Specifications</title>
        <author>
            <name>B. Claise</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Johnson</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>exporting process</kw>
            <kw>collecting process</kw>
            <kw>ipfix</kw>
            <kw>ip flow information export</kw>
        </keywords>
        <abstract><p>This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process.  For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient.  The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-psamp-protocol-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>psamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5476</errata-url>
        <doi>10.17487/RFC5476</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5477</doc-id>
        <title>Information Model for Packet Sampling Exports</title>
        <author>
            <name>T. Dietz</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>F. Dressler</name>
        </author>
        <author>
            <name>G. Carle</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>psamp</kw>
            <kw>ipfix</kw>
            <kw>ip flow information export</kw>
        </keywords>
        <abstract><p>This memo defines an information model for the Packet SAMPling (PSAMP) protocol.  It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process.  As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-psamp-info-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>psamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5477</errata-url>
        <doi>10.17487/RFC5477</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5478</doc-id>
        <title>IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces</title>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>us defense information systems agency</kw>
        </keywords>
        <abstract><p>This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-rph-new-namespaces-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5478</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5479</doc-id>
        <title>Requirements and Analysis of Media Security Management Protocols</title>
        <author>
            <name>D. Wing</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Fries</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>keying</kw>
            <kw>Secure RTP</kw>
            <kw>SRTP</kw>
        </keywords>
        <abstract><p>This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media.  In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways.  A number of proposals have been published and a summary of these proposals is in the appendix of this document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-sip-media-security-requirements-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5479</errata-url>
        <doi>10.17487/RFC5479</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5480</doc-id>
        <title>Elliptic Curve Cryptography Subject Public Key Information</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <author>
            <name>K. Yiu</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>x.509</kw>
            <kw>asn.1</kw>
            <kw>subjectPubicKeyInfo</kw>
        </keywords>
        <abstract><p>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography.  This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-ecc-subpubkeyinfo-11</draft>
        <updates>
            <doc-id>RFC3279</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8813</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5480</errata-url>
        <doi>10.17487/RFC5480</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5481</doc-id>
        <title>Packet Delay Variation Applicability Statement</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>active measurement</kw>
            <kw>ipdv</kw>
            <kw>pdv</kw>
            <kw>inter-packet delay variation</kw>
        </keywords>
        <abstract><p>Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.</p><p> Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ippm-delay-var-as-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC5481</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5482</doc-id>
        <title>TCP User Timeout Option</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Transmission Control Protocol</kw>
        </keywords>
        <abstract><p>The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed.  It is a local, per-connection parameter.  This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value.  This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly.  Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity.  Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-tcp-uto-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC5482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5483</doc-id>
        <title>ENUM Implementation Issues and Experiences</title>
        <author>
            <name>L. Conroy</name>
        </author>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>E.164</kw>
            <kw>NAPTR</kw>
            <kw>dynamic delegation discovery system</kw>
        </keywords>
        <abstract><p>This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others.  As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards.  Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol.  It does not revise the standards but is intended to provide technical input to future revisions of those documents.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-enum-experiences-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5483</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5484</doc-id>
        <title>Associating Time-Codes with RTP Streams</title>
        <author>
            <name>D. Singer</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>smpte</kw>
            <kw>society of motion picture and television engineers</kw>
            <kw>media stream</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-smpte-rtp-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5484</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5485</doc-id>
        <title>Digital Signatures on Internet-Draft Documents</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>cms</kw>
            <kw>cryptographic message syntax</kw>
            <kw>detached signature</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for digital signatures on Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-housley-internet-draft-sig-file-08</draft>
        <updated-by>
            <doc-id>RFC8358</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5485</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5486</doc-id>
        <title>Session Peering for Multimedia Interconnect (SPEERMINT) Terminology</title>
        <author>
            <name>D. Malas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Meyer</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-speermint-terminology-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speermint</wg_acronym>
        <doi>10.17487/RFC5486</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5487</doc-id>
        <title>Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode</title>
        <author>
            <name>M. Badra</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PSK</kw>
            <kw>Diffie-Hellman</kw>
            <kw>Key Exchange</kw>
            <kw>advanced encryption standard</kw>
            <kw>gcm</kw>
            <kw>digest algorithm</kw>
            <kw>ciphersuite</kw>
        </keywords>
        <abstract><p>RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS).  However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm.  This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-psk-new-mac-aes-gcm-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC5487</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5488</doc-id>
        <title>Network Mobility (NEMO) Management Information Base</title>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>G. Keeni</name>
        </author>
        <author>
            <name>K. Koide</name>
        </author>
        <author>
            <name>K. Nagami</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>NEMO-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community.  In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mext-nemo-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC5488</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5489</doc-id>
        <title>ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)</title>
        <author>
            <name>M. Badra</name>
        </author>
        <author>
            <name>I. Hajjeh</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>pre-shared key</kw>
            <kw> Diffie-Hellman</kw>
            <kw>Key Exchange</kw>
            <kw>Elliptic Curve Cryptography</kw>
        </keywords>
        <abstract><p>This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE).  These cipher suites provide Perfect Forward Secrecy (PFS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-tls-ecdhe-psk-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC5489</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5490</doc-id>
        <title>The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mail filtering</kw>
            <kw>fileinto</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-sieve-imapext-metadata-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC5490</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5491</doc-id>
        <title>GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>PIDF-LO</kw>
            <kw>civic</kw>
            <kw>geodetic</kw>
            <kw>location</kw>
            <kw>well-formed</kw>
            <kw>GeoShape</kw>
        </keywords>
        <abstract><p>The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information.  There are, however, circumstances that arise when information needs to be constrained in how it is represented.  In these circumstances, the range of options that need to be implemented are reduced.  There is growing interest in being able to use location information contained in a PIDF-LO for routing applications.  To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO).  This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO.  It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-pdif-lo-profile-14</draft>
        <updates>
            <doc-id>RFC4119</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7459</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5491</errata-url>
        <doi>10.17487/RFC5491</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5492</doc-id>
        <title>Capabilities Advertisement with BGP-4</title>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <date>
            <month>February</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>bgp</kw>
            <kw>idr</kw>
            <kw>border gateway protocol</kw>
            <kw>capabilities</kw>
        </keywords>
        <abstract><p>This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.</p><p> This document obsoletes RFC 3392. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-rfc3392bis-05</draft>
        <obsoletes>
            <doc-id>RFC3392</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8810</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5492</errata-url>
        <doi>10.17487/RFC5492</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5493</doc-id>
        <title>Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network</title>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>D. Bramanti</name>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>D. McDysan</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>pc</kw>
            <kw>spc</kw>
            <kw>soft permanent connection</kw>
            <kw>data plane traffic</kw>
        </keywords>
        <abstract><p>From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.</p><p> This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-pc-and-sc-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5493</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5494</doc-id>
        <title>IANA Allocation Guidelines for the Address Resolution Protocol (ARP)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IANA rules</kw>
            <kw>Address Resolution Protocol</kw>
            <kw>ARP</kw>
        </keywords>
        <abstract><p>This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP).  This document also reserves some numbers for experimentation purposes.  The changes also affect other protocols that employ values from the ARP name spaces. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-arkko-arp-iana-rules-06</draft>
        <updates>
            <doc-id>RFC0826</doc-id>
            <doc-id>RFC0951</doc-id>
            <doc-id>RFC1044</doc-id>
            <doc-id>RFC1329</doc-id>
            <doc-id>RFC2131</doc-id>
            <doc-id>RFC2132</doc-id>
            <doc-id>RFC2176</doc-id>
            <doc-id>RFC2225</doc-id>
            <doc-id>RFC2834</doc-id>
            <doc-id>RFC2835</doc-id>
            <doc-id>RFC3315</doc-id>
            <doc-id>RFC4338</doc-id>
            <doc-id>RFC4361</doc-id>
            <doc-id>RFC4701</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5494</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5495</doc-id>
        <title>Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures</title>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>J. Gao</name>
        </author>
        <author>
            <name>A. Satyanarayana</name>
        </author>
        <author>
            <name>S. Bardalai</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Hello message</kw>
            <kw>gmpls</kw>
        </keywords>
        <abstract><p>The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.</p><p> The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).</p><p> Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.</p><p> This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.</p><p> This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gr-description-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5495</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5496</doc-id>
        <title>The Reverse Path Forwarding (RPF) Vector TLV</title>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>A. Boers</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>pim</kw>
            <kw>protocol independent multicast join attribute</kw>
        </keywords>
        <abstract><p>This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-rpf-vector-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5496</errata-url>
        <doi>10.17487/RFC5496</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5497</doc-id>
        <title>Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Routing Protocol</kw>
            <kw>TLV</kw>
            <kw>Fisheye</kw>
            <kw>FSR</kw>
            <kw>Fuzzy-Sighted</kw>
            <kw>extension</kw>
            <kw>packetbb</kw>
            <kw>RFC5444</kw>
        </keywords>
        <abstract><p>This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format.  It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-manet-timetlv-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5497</errata-url>
        <doi>10.17487/RFC5497</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5498</doc-id>
        <title>IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols</title>
        <author>
            <name>I. Chakeres</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>manet protocols</kw>
        </keywords>
        <abstract><p>This document enumerates several common IANA allocations for use by Mobile Ad hoc NETwork (MANET) protocols.  The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-manet-iana-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5498</errata-url>
        <doi>10.17487/RFC5498</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5499</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5500</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5501</doc-id>
        <title>Requirements for Multicast Support in Virtual Private LAN Services</title>
        <author>
            <name>Y. Kamite</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Wada</name>
        </author>
        <author>
            <name>Y. Serbest</name>
        </author>
        <author>
            <name>T. Morin</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>L2</kw>
            <kw>VPN</kw>
            <kw>VPLS</kw>
            <kw>Ethernet</kw>
            <kw>P2MP</kw>
            <kw>IGMP</kw>
            <kw>MLD</kw>
            <kw>PIM</kw>
        </keywords>
        <abstract><p>This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS).  It specifies requirements both from the end user and service provider standpoints.  It is intended that potential solutions will use these requirements as guidelines.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-mcast-reqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC5501</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5502</doc-id>
        <title>The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem</title>
        <author>
            <name>J. van Elburg</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>S-CSCF</kw>
            <kw>AS</kw>
            <kw>ISC</kw>
        </keywords>
        <abstract><p>This document specifies the SIP P-Served-User P-header.  This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface.  This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-vanelburg-sipping-served-user-08</draft>
        <updated-by>
            <doc-id>RFC8217</doc-id>
            <doc-id>RFC8498</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5502</errata-url>
        <doi>10.17487/RFC5502</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5503</doc-id>
        <title>Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>B. McKibben</name>
        </author>
        <author>
            <name>B. Marshall</name>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>P-DCS-TRACE-PARTY-ID</kw>
            <kw>P-DCS-OSPS</kw>
            <kw>P-DCS-BILLING-INFO</kw>
            <kw>P-DCS-LAES</kw>
            <kw>P-DCS-Redirect</kw>
            <kw>P-DCS-INFO</kw>
        </keywords>
        <abstract><p>In order to deploy a residential telephone service at a 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, RFC 3261, 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.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-andreasen-sipping-rfc3603bis-07</draft>
        <obsoletes>
            <doc-id>RFC3603</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5503</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5504</doc-id>
        <title>Downgrading Mechanism for Email Address Internationalization</title>
        <author>
            <name>K. Fujiwara</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Yoneya</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>Email Address Internationalization</kw>
            <kw>Downgrade</kw>
            <kw>MAIL</kw>
        </keywords>
        <abstract><p>Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields.  The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields.  To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required.  This document describes a downgrading mechanism for Email Address Internationalization.  Note that this is a way to downgrade, not tunnel.  There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-downgrade-12</draft>
        <obsoleted-by>
            <doc-id>RFC6530</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC5504</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5505</doc-id>
        <title>Principles of Internet Host Configuration</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>internet-layer parameter</kw>
            <kw>higher-layer configuration</kw>
        </keywords>
        <abstract><p>This document describes principles of Internet host configuration.  It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-ip-config-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5505</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5506</doc-id>
        <title>Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences</title>
        <author>
            <name>I. Johansson</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>AVPF</kw>
            <kw>non-compound</kw>
            <kw>non compound</kw>
            <kw>compound</kw>
        </keywords>
        <abstract><p>This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size.  The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed.  Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585).  This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtcp-non-compound-09</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
            <doc-id>RFC3711</doc-id>
            <doc-id>RFC4585</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5506</errata-url>
        <doi>10.17487/RFC5506</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5507</doc-id>
        <title>Design Choices When Expanding the DNS</title>
        <author>
            <name>IAB</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Austein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Koch</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>resource record type</kw>
        </keywords>
        <abstract><p>This note discusses how to extend the DNS with new data for a new application.  DNS extension discussions too often focus on reuse of the TXT Resource Record Type.  This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-dns-choices-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5507</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5508</doc-id>
        <title>NAT Behavioral Requirements for ICMP</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>B. Ford</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>S. Guha</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>ICMP Error payload translation</kw>
            <kw>hairpin translation</kw>
            <kw>ICMP Query</kw>
            <kw>ICMP Error</kw>
            <kw>Ping</kw>
            <kw>Traceroute</kw>
        </keywords>
        <abstract><p>This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP).  The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices.  Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-behave-nat-icmp-12</draft>
        <updated-by>
            <doc-id>RFC7857</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0148</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC5508</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5509</doc-id>
        <title>Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>_sip</kw>
        </keywords>
        <abstract><p>This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]</p></abstract>
        <draft>draft-loreto-simple-im-srv-label-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5509</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5510</doc-id>
        <title>Reed-Solomon Forward Error Correction (FEC) Schemes</title>
        <author>
            <name>J. Lacan</name>
        </author>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>J. Peltotalo</name>
        </author>
        <author>
            <name>S. Peltotalo</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>maximum distance separable</kw>
            <kw>MDS</kw>
        </keywords>
        <abstract><p>This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).</p><p> Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-rs-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC5510</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5511</doc-id>
        <title>Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>routing bnf</kw>
        </keywords>
        <abstract><p>Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.</p><p> There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.</p><p> Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.</p><p> This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-farrel-rtg-common-bnf-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5511</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5512</doc-id>
        <title>The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute</title>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>Encapsulation</kw>
            <kw>Encap SAFI</kw>
            <kw>Tunnel</kw>
            <kw>Softwire</kw>
            <kw>4over6</kw>
            <kw>6over4</kw>
        </keywords>
        <abstract><p>In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.</p><p> The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-encaps-safi-05</draft>
        <obsoleted-by>
            <doc-id>RFC9012</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5512</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5513</doc-id>
        <title>IANA Considerations for Three Letter Acronyms</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>tla</kw>
            <kw>abbreviation</kw>
        </keywords>
        <abstract><p>Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.</p><p> Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-farrel-iana-tla-registry-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5513</errata-url>
        <doi>10.17487/RFC5513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5514</doc-id>
        <title>IPv6 over Social Networks</title>
        <author>
            <name>E. Vyncke</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>facebook</kw>
        </keywords>
        <abstract><p>There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low.  This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.  This will immediately add millions of IPv6 hosts to the existing IPv6 Internet.  This document includes sections on addressing and transport of IPv6 over a Social Network.  A working prototype has been developed.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-vyncke-ip-over-social-network-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5514</errata-url>
        <doi>10.17487/RFC5514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5515</doc-id>
        <title>Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions</title>
        <author>
            <name>V. Mammoliti</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>P. Arberg</name>
        </author>
        <author>
            <name>J. Gibbons</name>
        </author>
        <author>
            <name>P. Howard</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>L2TP</kw>
            <kw>Acces Line Information</kw>
            <kw>DSLAM</kw>
        </keywords>
        <abstract><p>This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality.  It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment.  The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products.  The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-mammoliti-l2tp-accessline-avp-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5515</errata-url>
        <doi>10.17487/RFC5515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5516</doc-id>
        <title>Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>L. Morand</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>3GPP</kw>
            <kw>Release 8</kw>
            <kw>Diameter</kw>
            <kw>command codes</kw>
            <kw>EPS</kw>
        </keywords>
        <abstract><p>This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS).  These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-jones-dime-3gpp-eps-command-codes-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5516</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5517</doc-id>
        <title>Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment</title>
        <author>
            <name>S. HomChaudhuri</name>
        </author>
        <author>
            <name>M. Foschiano</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.</p><p> Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-sanjib-private-vlan-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5517</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5518</doc-id>
        <title>Vouch By Reference</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>A. Hathcock</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>VBR</kw>
            <kw>DKIM</kw>
            <kw>SenderID</kw>
            <kw>DK</kw>
            <kw>reputation</kw>
        </keywords>
        <abstract><p>This document describes the Vouch By Reference (VBR) protocol.  VBR is a protocol for adding third-party certification to email.  It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hoffman-dac-vbr-07</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5518</errata-url>
        <doi>10.17487/RFC5518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5519</doc-id>
        <title>Multicast Group Membership Discovery MIB</title>
        <author>
            <name>J. Chesterfield</name>
        </author>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>mgmd</kw>
            <kw>mld</kw>
            <kw>multicast listener discovery</kw>
            <kw>MGMD-STD-MIB</kw>
        </keywords>
        <abstract><p>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) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-magma-mgmd-mib-15</draft>
        <obsoletes>
            <doc-id>RFC2933</doc-id>
            <doc-id>RFC3019</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>magma</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5519</errata-url>
        <doi>10.17487/RFC5519</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5520</doc-id>
        <title>Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism</title>
        <author>
            <name>R. Bradford</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>confidential path segment</kw>
            <kw>cps</kw>
            <kw>pcep</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.</p><p> This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-path-key-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5520</errata-url>
        <doi>10.17487/RFC5520</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5521</doc-id>
        <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions</title>
        <author>
            <name>E. Oki</name>
        </author>
        <author>
            <name>T. Takeda</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>GMPLS</kw>
            <kw>Traffic Engineering</kw>
            <kw>Label Switched Path</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</p><p> When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".</p><p> The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-pcep-xro-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5521</errata-url>
        <doi>10.17487/RFC5521</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5522</doc-id>
        <title>Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks</title>
        <author>
            <name>W. Eddy</name>
        </author>
        <author>
            <name>W. Ivancic</name>
        </author>
        <author>
            <name>T. Davis</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>NEMO</kw>
            <kw>aeronautics</kw>
            <kw>space exploration</kw>
            <kw>route optimization</kw>
            <kw>mobility</kw>
        </keywords>
        <abstract><p>This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.</p><p> Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mext-aero-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC5522</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5523</doc-id>
        <title>OSPFv3-Based Layer 1 VPN Auto-Discovery</title>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>layer 1 virtual private network</kw>
        </keywords>
        <abstract><p>This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism.  This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism.  The notable functional difference is the support of IPv6.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-l1vpn-ospfv3-auto-discovery-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l1vpn</wg_acronym>
        <doi>10.17487/RFC5523</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5524</doc-id>
        <title>Extended URLFETCH for Binary and Converted Parts</title>
        <author>
            <name>D. Cridland</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>Lemonade</kw>
        </keywords>
        <abstract><p>The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications.  This memo specifies a method for obtaining data in forms suitable for non-mail applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-cridland-urlfetch-binary-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5524</errata-url>
        <doi>10.17487/RFC5524</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5525</doc-id>
        <title>Reliable Server Pooling MIB Module Definition</title>
        <author>
            <name>T. Dreibholz</name>
        </author>
        <author>
            <name>J. Mulik</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>RSerPool</kw>
            <kw>Management Information Base</kw>
            <kw>asap</kw>
            <kw>aggregate server access protocol</kw>
            <kw>enrp</kw>
            <kw>endpoint handlespace redundancy protocol</kw>
            <kw>RSERPOOL-MIB</kw>
        </keywords>
        <abstract><p>Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling.  The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol).  This document defines an \%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-rserpool-mib-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rserpool</wg_acronym>
        <doi>10.17487/RFC5525</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5526</doc-id>
        <title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM</title>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>P. Pfautz</name>
        </author>
        <author>
            <name>R. Stastny</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>e164.arpa</kw>
        </keywords>
        <abstract><p>This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees).  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-enum-infrastructure-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5527</doc-id>
        <title>Combined User and Infrastructure ENUM in the e164.arpa Tree</title>
        <author>
            <name>M. Haberler</name>
        </author>
        <author>
            <name>O. Lendl</name>
        </author>
        <author>
            <name>R. Stastny</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>e164.arpa</kw>
        </keywords>
        <abstract><p>This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice.  This interim solution will be deprecated after implementation of the long-term solution.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-enum-combined-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC5527</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5528</doc-id>
        <title>Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms</title>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>M. Kanda</name>
        </author>
        <author>
            <name>S. Kanno</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Camellia</kw>
            <kw>Block Cipher</kw>
            <kw>Mode of operation</kw>
        </keywords>
        <abstract><p>This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM).  The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-kato-camellia-ctrccm-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5528</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5529</doc-id>
        <title>Modes of Operation for Camellia for Use with IPsec</title>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>M. Kanda</name>
        </author>
        <author>
            <name>S. Kanno</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>Camellia</kw>
            <kw>Block Cipher</kw>
            <kw>Mode of operation</kw>
        </keywords>
        <abstract><p>This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kato-ipsec-camellia-modes-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5529</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5530</doc-id>
        <title>IMAP Response Codes</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>machine-readable response codes</kw>
        </keywords>
        <abstract><p>IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.</p><p> This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gulbrandsen-imap-response-codes-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5530</errata-url>
        <doi>10.17487/RFC5530</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5531</doc-id>
        <title>RPC: Remote Procedure Call Protocol Specification Version 2</title>
        <author>
            <name>R. Thurlow</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>RPC</kw>
            <kw>ONC</kw>
            <kw>Open Network Computing</kw>
        </keywords>
        <abstract><p>This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted.  This document obsoletes RFC 1831. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-rfc1831bis-13</draft>
        <obsoletes>
            <doc-id>RFC1831</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9289</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5531</errata-url>
        <doi>10.17487/RFC5531</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5532</doc-id>
        <title>Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement</title>
        <author>
            <name>T. Talpey</name>
        </author>
        <author>
            <name>C. Juszczak</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>RPC</kw>
            <kw>XDR</kw>
            <kw>ONC</kw>
            <kw>RDDP</kw>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols.  NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead.  This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-nfsv4-nfs-rdma-problem-statement-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC5532</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5533</doc-id>
        <title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>locator pair</kw>
        </keywords>
        <abstract><p>This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table.  The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-shim6-proto-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>shim6</wg_acronym>
        <doi>10.17487/RFC5533</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5534</doc-id>
        <title>Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>I. van Beijnum</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Shim6</kw>
            <kw>reachability protocol</kw>
            <kw>REAP</kw>
        </keywords>
        <abstract><p>This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes.  It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-shim6-failure-detection-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>shim6</wg_acronym>
        <doi>10.17487/RFC5534</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5535</doc-id>
        <title>Hash-Based Addresses (HBA)</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Shim6</kw>
            <kw>multi-homing</kw>
            <kw>cryptographically generated addresses (cgas),</kw>
        </keywords>
        <abstract><p>This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site.  This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses.  The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves.  This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number.  Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers.  The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-shim6-hba-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>shim6</wg_acronym>
        <doi>10.17487/RFC5535</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5536</doc-id>
        <title>Netnews Article Format</title>
        <author>
            <name>K. Murchison</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Lindsey</name>
        </author>
        <author>
            <name>D. Kohn</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Usenet</kw>
            <kw>Usefor</kw>
        </keywords>
        <abstract><p>This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045).  This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-usefor-usefor-12</draft>
        <obsoletes>
            <doc-id>RFC1036</doc-id>
            <doc-id>RFC1849</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>usefor</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5536</errata-url>
        <doi>10.17487/RFC5536</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5537</doc-id>
        <title>Netnews Architecture and Protocols</title>
        <author>
            <name>R. Allbery</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Lindsey</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>usefor</kw>
            <kw>Usenet</kw>
            <kw>netnews</kw>
        </keywords>
        <abstract><p>This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them.  It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-usefor-usepro-14</draft>
        <obsoletes>
            <doc-id>RFC1036</doc-id>
            <doc-id>RFC1849</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8315</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>usefor</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5537</errata-url>
        <doi>10.17487/RFC5537</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5538</doc-id>
        <title>The 'news' and 'nntp' URI Schemes</title>
        <author>
            <name>F. Ellermann</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738.  The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ellermann-news-nntp-uri-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5538</errata-url>
        <doi>10.17487/RFC5538</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5539</doc-id>
        <title>NETCONF over Transport Layer Security (TLS)</title>
        <author>
            <name>M. Badra</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Authentication</kw>
            <kw>TLS</kw>
            <kw>RPC</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.  This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-tls-07</draft>
        <obsoleted-by>
            <doc-id>RFC7589</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC5539</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5540</doc-id>
        <title>40 Years of RFCs</title>
        <author>
            <name>RFC Editor</name>
        </author>
        <date>
            <month>April</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This RFC marks the 40th anniversary of the RFC document series.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-rfc-editor-40-anniversary-00</draft>
        <updated-by>
            <doc-id>RFC8700</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5540</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5541</doc-id>
        <title>Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)</title>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>pcc</kw>
            <kw>path computation client</kw>
        </keywords>
        <abstract><p>The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).</p><p> In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.</p><p> This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.</p><p> This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-of-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC5541</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5542</doc-id>
        <title>Definitions of Textual Conventions for Pseudowire (PW) Management</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Zelig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Nicklass</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Pseudowire</kw>
            <kw>PWE3</kw>
            <kw>MIB</kw>
            <kw>PWE3-TC</kw>
            <kw>PW-TC</kw>
        </keywords>
        <abstract><p>This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information.  The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-pw-tc-mib-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5542</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5543</doc-id>
        <title>BGP Traffic Engineering Attribute</title>
        <author>
            <name>H. Ould-Brahim</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>BGP-TE</kw>
            <kw>BGP-TE Attribute</kw>
            <kw>Traffic Engineering with BGP</kw>
            <kw>Inter-domain Traffic Engineering</kw>
            <kw>L1VPN BGP-TE</kw>
            <kw>BGP-TE-VPN</kw>
            <kw>VPN BGP Traffic Engineering Attribute</kw>
        </keywords>
        <abstract><p>This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.</p><p> The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-bgp-te-attribute-04</draft>
        <updated-by>
            <doc-id>RFC7606</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5544</doc-id>
        <title>Syntax for Binding Documents with Time-Stamps</title>
        <author>
            <name>A. Santoni</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>time-stamp token,</kw>
        </keywords>
        <abstract><p>This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.</p><p> The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-santoni-timestampeddata-06</draft>
        <updated-by>
            <doc-id>RFC5955</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5544</errata-url>
        <doi>10.17487/RFC5544</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5545</doc-id>
        <title>Internet Calendaring and Scheduling Core Object Specification (iCalendar)</title>
        <author>
            <name>B. Desruisseaux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>168</page-count>
        <keywords>
            <kw>calsify</kw>
            <kw>calsched</kw>
            <kw>calsch</kw>
            <kw>caldav</kw>
            <kw>calendar</kw>
            <kw>calendaring</kw>
            <kw>meeting</kw>
            <kw>event</kw>
            <kw>task</kw>
            <kw>to-do</kw>
            <kw>journal</kw>
            <kw>appointment</kw>
            <kw>agenda</kw>
            <kw>schedule</kw>
            <kw>scheduling</kw>
            <kw>ical</kw>
            <kw>icalendar</kw>
            <kw>itip</kw>
            <kw>imip</kw>
            <kw>text/calendar</kw>
            <kw>ischedule</kw>
            <kw>xCalendar</kw>
        </keywords>
        <abstract><p>This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-calsify-rfc2445bis-10</draft>
        <obsoletes>
            <doc-id>RFC2445</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC5546</doc-id>
            <doc-id>RFC6868</doc-id>
            <doc-id>RFC7529</doc-id>
            <doc-id>RFC7953</doc-id>
            <doc-id>RFC7986</doc-id>
            <doc-id>RFC9073</doc-id>
            <doc-id>RFC9074</doc-id>
            <doc-id>RFC9253</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsify</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5545</errata-url>
        <doi>10.17487/RFC5545</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5546</doc-id>
        <title>iCalendar Transport-Independent Interoperability Protocol (iTIP)</title>
        <author>
            <name>C. Daboo</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>133</page-count>
        <keywords>
            <kw>calendar</kw>
            <kw>scheduling</kw>
        </keywords>
        <abstract><p>This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.</p><p> The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-calsify-2446bis-10</draft>
        <obsoletes>
            <doc-id>RFC2446</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5545</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6638</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsify</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5546</errata-url>
        <doi>10.17487/RFC5546</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5547</doc-id>
        <title>A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>M. Isomaki</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>msrp</kw>
            <kw>message session relay protocol</kw>
        </keywords>
        <abstract><p>This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264.  SDP is extended to describe the attributes of the files to be transferred.  The offerer can describe either the files it wants to send or the files it would like to receive.  The answerer can either accept or reject the offer separately for each individual file.  The transfer of one or more files is initiated after a successful negotiation.  The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints.  The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-file-transfer-mech-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5547</errata-url>
        <doi>10.17487/RFC5547</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5548</doc-id>
        <title>Routing Requirements for Urban Low-Power and Lossy Networks</title>
        <author>
            <name>M. Dohler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Watteyne</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Winter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Barthel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>u-lln</kw>
            <kw>roll</kw>
            <kw>routing over low-power and loss</kw>
        </keywords>
        <abstract><p>The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document.  In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws.  These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions).  The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols.  The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios.  As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous.  This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-roll-urban-routing-reqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC5548</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5549</doc-id>
        <title>Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>IPv6</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract><p>Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).  The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol.  This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-v4nlri-v6nh-02</draft>
        <obsoleted-by>
            <doc-id>RFC8950</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5549</errata-url>
        <doi>10.17487/RFC5549</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5550</doc-id>
        <title>The Internet Email to Support Diverse Service Environments (Lemonade) Profile</title>
        <author>
            <name>D. Cridland</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Maes</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>Sieve</kw>
            <kw>SMTP</kw>
            <kw>Lemonade</kw>
            <kw>mobile email</kw>
            <kw>low-bandwidth efficient</kw>
        </keywords>
        <abstract><p>This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.</p><p> The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-lemonade-profile-bis-12</draft>
        <obsoletes>
            <doc-id>RFC4550</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4469</doc-id>
            <doc-id>RFC4467</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5551</doc-id>
        <title>Lemonade Notifications Architecture</title>
        <author>
            <name>R. Gellens</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>notification</kw>
            <kw>filtering</kw>
        </keywords>
        <abstract><p>Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group.</p><p> This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-lemonade-notifications-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <doi>10.17487/RFC5551</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5552</doc-id>
        <title>SIP Interface to VoiceXML Media Services</title>
        <author>
            <name>D. Burke</name>
        </author>
        <author>
            <name>M. Scott</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>VoiceXML</kw>
            <kw>SIP</kw>
            <kw>MRF</kw>
            <kw>IVR</kw>
            <kw>IMS</kw>
        </keywords>
        <abstract><p>This document describes a SIP interface to VoiceXML media services.  Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities.  This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mediactrl-vxml-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5552</errata-url>
        <doi>10.17487/RFC5552</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5553</doc-id>
        <title>Resource Reservation Protocol (RSVP) Extensions for Path Key Support</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Bradford</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>pks</kw>
            <kw>path key subobject</kw>
            <kw>ero</kw>
            <kw>explicit route object</kw>
            <kw>rro</kw>
            <kw>record route object</kw>
        </keywords>
        <abstract><p>The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.</p><p> To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.</p><p> This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-path-key-ero-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5553</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5554</doc-id>
        <title>Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>GSS</kw>
            <kw>GSS-API</kw>
            <kw>channel binding</kw>
            <kw>and C-bindings</kw>
        </keywords>
        <abstract><p>This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-gssapi-channel-bindings-07</draft>
        <updates>
            <doc-id>RFC2743</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC5554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5555</doc-id>
        <title>Mobile IPv6 Support for Dual Stack Hosts and Routers</title>
        <author>
            <name>H. Soliman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>nemo</kw>
            <kw>mipv6</kw>
            <kw>ipv4</kw>
        </keywords>
        <abstract><p>The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only.  This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent.  This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mext-nemo-v4traversal-10</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5555</errata-url>
        <doi>10.17487/RFC5555</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5556</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>spanning tree protocol</kw>
            <kw>ieee 802.1</kw>
        </keywords>
        <abstract><p>Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges.  These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support.  Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees).  This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer.  This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-trill-prob-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5556</errata-url>
        <doi>10.17487/RFC5556</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5557</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization</title>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>E. Oki</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>pcc</kw>
            <kw>path communication client</kw>
            <kw>pce</kw>
            <kw>gco</kw>
            <kw>global concurrent optimization</kw>
            <kw>nms</kw>
            <kw>network management system</kw>
        </keywords>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.</p><p> This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-global-concurrent-optimization-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5557</errata-url>
        <doi>10.17487/RFC5557</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5558</doc-id>
        <title>Virtual Enterprise Traversal (VET)</title>
        <author>
            <name>F. Templin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Enterprise</kw>
            <kw>MANET</kw>
            <kw>Encapsulation</kw>
            <kw>Tunneling</kw>
            <kw>Autoconfiguration</kw>
            <kw>Subnetwork</kw>
            <kw>Provider-Independent</kw>
            <kw>Provider-Aggregated</kw>
        </keywords>
        <abstract><p>Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet.  Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself.  This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-templin-autoconf-dhcp-38</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5558</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5559</doc-id>
        <title>Pre-Congestion Notification (PCN) Architecture</title>
        <author>
            <name>P. Eardley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Congestion Control</kw>
            <kw>Differentiated Services</kw>
            <kw>Admission Control</kw>
            <kw>Termination</kw>
        </keywords>
        <abstract><p>This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pcn-architecture-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5559</errata-url>
        <doi>10.17487/RFC5559</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5560</doc-id>
        <title>A One-Way Packet Duplication Metric</title>
        <author>
            <name>H. Uijterwaal</name>
        </author>
        <date>
            <month>May</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>performance metrics</kw>
            <kw>packet duplication</kw>
            <kw>unidirectional</kw>
        </keywords>
        <abstract><p>When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.</p><p> In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-duplicate-08</draft>
        <updated-by>
            <doc-id>RFC6248</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC5560</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5561</doc-id>
        <title>LDP Capabilities</title>
        <author>
            <name>B. Thomas</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>S. Aggarwal</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LDP</kw>
            <kw>Capabilities</kw>
        </keywords>
        <abstract><p>A number of enhancements to the Label Distribution Protocol (LDP) have been proposed.  Some have been implemented, and some are advancing toward standardization.  It is likely that additional enhancements will be proposed in the future.  This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-capabilities-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5561</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5562</doc-id>
        <title>Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets</title>
        <author>
            <name>A. Kuzmanovic</name>
        </author>
        <author>
            <name>A. Mondal</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>ecn-capable</kw>
        </keywords>
        <abstract><p>The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.</p><p> This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-ecnsyn-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC5562</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5563</doc-id>
        <title>WiMAX Forum / 3GPP2 Proxy Mobile IPv4</title>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>P. Yegani</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>mipv4</kw>
            <kw>pmipv4</kw>
        </keywords>
        <abstract><p>Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address.  The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent.  However, there are many IPv4 devices without such capability due to various reasons.  This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device.  This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-leung-mip4-proxy-mode-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5563</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5564</doc-id>
        <title>Linguistic Guidelines for the Use of the Arabic Language in Internet Domains</title>
        <author>
            <name>A. El-Sherbiny</name>
        </author>
        <author>
            <name>M. Farah</name>
        </author>
        <author>
            <name>I. Oueichek</name>
        </author>
        <author>
            <name>A. Al-Zoman</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>arabic domain names</kw>
        </keywords>
        <abstract><p>This document constitutes technical specifications for the use of Arabic in Internet domain names and provides linguistic guidelines for Arabic domain names.  It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-farah-adntf-ling-guidelines-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5564</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5565</doc-id>
        <title>Softwire Mesh Framework</title>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Internet needs to be able to handle both IPv4 and IPv6 packets.  However, it is expected that some constituent networks of the Internet will be "single-protocol" networks.  One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information.  It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol.  This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other.  The tunnels are known as "softwires".  This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol.  The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-mesh-framework-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5565</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5566</doc-id>
        <title>BGP IPsec Tunnel Encapsulation Attribute</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>safi</kw>
            <kw>subsequent address family identifier</kw>
        </keywords>
        <abstract><p>The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops.  Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined.  This document defines support for IPsec tunnel types. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-encaps-ipsec-03</draft>
        <obsoleted-by>
            <doc-id>RFC9012</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5566</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5567</doc-id>
        <title>An Architectural Framework for Media Server Control</title>
        <author>
            <name>T. Melanchuk</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document describes an architectural framework for Media Server control.  The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mediactrl-architecture-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <doi>10.17487/RFC5567</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5568</doc-id>
        <title>Mobile IPv6 Fast Handovers</title>
        <author>
            <name>R. Koodli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>mpiv6</kw>
            <kw>handover latency</kw>
        </keywords>
        <abstract><p>Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.</p><p> This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-rfc5268bis-01</draft>
        <obsoletes>
            <doc-id>RFC5268</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7411</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5568</errata-url>
        <doi>10.17487/RFC5568</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5569</doc-id>
        <title>IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)</title>
        <author>
            <name>R. Despres</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IPv4</kw>
            <kw>migration</kw>
            <kw>transition</kw>
            <kw>6to4</kw>
            <kw>6rd</kw>
        </keywords>
        <abstract><p>IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment.  Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure.  Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix.  A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-despres-6rd-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5569</errata-url>
        <doi>10.17487/RFC5569</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5570</doc-id>
        <title>Common Architecture Label IPv6 Security Option (CALIPSO)</title>
        <author>
            <name>M. StJohns</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <author>
            <name>G. Thomas</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>sensitivity labels</kw>
            <kw>mls</kw>
            <kw>multi-level secure</kw>
        </keywords>
        <abstract><p>This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets.  It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-stjohns-sipso-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5570</errata-url>
        <doi>10.17487/RFC5570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5571</doc-id>
        <title>Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)</title>
        <author>
            <name>B. Storer</name>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Dos Santos</name>
        </author>
        <author>
            <name>B. Stevant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <author>
            <name>J. Tremblay</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Softwire</kw>
            <kw>L2TP</kw>
            <kw>Softwire Hub and Spoke</kw>
            <kw>Softwire HnS</kw>
            <kw>4over6</kw>
            <kw>6over4</kw>
            <kw>L2TP softwires</kw>
            <kw>L2TPv2 softwires</kw>
        </keywords>
        <abstract><p>This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2).  The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-hs-framework-l2tpv2-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5571</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5572</doc-id>
        <title>IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>F. Parent</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Tunnel</kw>
            <kw>Transition</kw>
            <kw>TSP</kw>
        </keywords>
        <abstract><p>A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal.  The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker.  A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only.  A tunnel broker may terminate the tunnels on remote tunnel servers or on itself.  This document describes the TSP within the model of the tunnel broker model.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-blanchet-v6ops-tunnelbroker-tsp-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5572</errata-url>
        <doi>10.17487/RFC5572</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5573</doc-id>
        <title>Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>asynchronous beep channels</kw>
        </keywords>
        <abstract><p>The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols.  This document describes a BEEP feature that enables asynchrony for individual channels.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-thomson-beep-async-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5573</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5574</doc-id>
        <title>RTP Payload Format for the Speex Codec</title>
        <author>
            <name>G. Herlein</name>
        </author>
        <author>
            <name>J. Valin</name>
        </author>
        <author>
            <name>A. Heggestad</name>
        </author>
        <author>
            <name>A. Moizard</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Voip</kw>
            <kw>SDP</kw>
            <kw>audio</kw>
            <kw>CELLP</kw>
            <kw>Xiph.Org</kw>
        </keywords>
        <abstract><p>Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications.  This document describes the payload format for Speex-generated bit streams within an RTP packet.  Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-speex-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5574</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5575</doc-id>
        <title>Dissemination of Flow Specification Rules</title>
        <author>
            <name>P. Marques</name>
        </author>
        <author>
            <name>N. Sheth</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>B. Greene</name>
        </author>
        <author>
            <name>J. Mauch</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IDR</kw>
            <kw>Inter-domain routing</kw>
            <kw>BGP</kw>
            <kw>DDOS</kw>
            <kw>Denial of Service</kw>
            <kw>ACL</kw>
            <kw>Firewall</kw>
            <kw>Filter</kw>
        </keywords>
        <abstract><p>This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</p><p> Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.</p><p> The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-flow-spec-09</draft>
        <obsoleted-by>
            <doc-id>RFC8955</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7674</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5575</errata-url>
        <doi>10.17487/RFC5575</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5576</doc-id>
        <title>Source-Specific Media Attributes in the Session Description Protocol (SDP)</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>T. Schierl</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>rtp</kw>
            <kw>synchronization source</kw>
            <kw>ssrc</kw>
            <kw>fid</kw>
            <kw>flow identification</kw>
            <kw>fec</kw>
            <kw>forward error correction</kw>
        </keywords>
        <abstract><p>The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream.  This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources.  It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-source-attributes-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5576</errata-url>
        <doi>10.17487/RFC5576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5577</doc-id>
        <title>RTP Payload Format for ITU-T Recommendation G.722.1</title>
        <author>
            <name>P. Luthi</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>international telecommunication union</kw>
            <kw>wide-band audio coded</kw>
        </keywords>
        <abstract><p>International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec.  This document describes the payload format for including G.722.1-generated bit streams within an RTP packet.  The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rfc3047-bis-09</draft>
        <obsoletes>
            <doc-id>RFC3047</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5577</errata-url>
        <doi>10.17487/RFC5577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5578</doc-id>
        <title>PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics</title>
        <author>
            <name>B. Berry</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Ratliff</name>
        </author>
        <author>
            <name>E. Paradise</name>
        </author>
        <author>
            <name>T. Kaiser</name>
        </author>
        <author>
            <name>M. Adams</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>point-to-point protocol over ethernet</kw>
            <kw>link quality metric</kw>
        </keywords>
        <abstract><p>This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report.  These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-bberry-rfc4938bis-00</draft>
        <obsoletes>
            <doc-id>RFC4938</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5578</errata-url>
        <doi>10.17487/RFC5578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5579</doc-id>
        <title>Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces</title>
        <author>
            <name>F. Templin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ISATAP</kw>
            <kw>Tunnel</kw>
            <kw>Encapsulation</kw>
            <kw>Map-and-Encaps</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation.  The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however.  This document specifies a method for transmitting IPv4 packets over ISATAP interfaces.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-templin-isatapv4-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5580</doc-id>
        <title>Carrying Location Objects in RADIUS and Diameter</title>
        <author>
            <name>H. Tschofenig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Adrangi</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>remote authentication dial-in user service</kw>
            <kw>location information</kw>
        </keywords>
        <abstract><p>This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.</p><p> The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-radius-lo-24</draft>
        <updated-by>
            <doc-id>RFC8559</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5580</errata-url>
        <doi>10.17487/RFC5580</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5581</doc-id>
        <title>The Camellia Cipher in OpenPGP</title>
        <author>
            <name>D. Shaw</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>PGP</kw>
            <kw>GPG</kw>
            <kw>GnuPG</kw>
            <kw>Encryption</kw>
            <kw>Symmetric</kw>
        </keywords>
        <abstract><p>This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-openpgp-camellia-04</draft>
        <obsoleted-by>
            <doc-id>RFC9580</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4880</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5581</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5582</doc-id>
        <title>Location-to-URL Mapping Architecture and Framework</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ECRIT</kw>
            <kw>Mapping</kw>
            <kw>LoST</kw>
            <kw>Emergency calling</kw>
        </keywords>
        <abstract><p>This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol.  The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ecrit-mapping-arch-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5582</errata-url>
        <doi>10.17487/RFC5582</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5583</doc-id>
        <title>Signaling Media Decoding Dependency in the Session Description Protocol (SDP)</title>
        <author>
            <name>T. Schierl</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>media coding</kw>
            <kw>ddp</kw>
            <kw>decoding dependency</kw>
        </keywords>
        <abstract><p>This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.</p><p> A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-decoding-dependency-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5583</errata-url>
        <doi>10.17487/RFC5583</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5584</doc-id>
        <title>RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family</title>
        <author>
            <name>M. Hatanaka</name>
        </author>
        <author>
            <name>J. Matsumoto</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>audio</kw>
            <kw>fragmentation</kw>
            <kw>layered coding</kw>
            <kw>multiplexed</kw>
            <kw>multi-session</kw>
            <kw>multi-channel</kw>
            <kw>redundancy</kw>
            <kw>scalable</kw>
            <kw>ATRAC</kw>
            <kw>ATRAC3</kw>
            <kw>ATRAC-X</kw>
            <kw>ATRAC Advanced Lossless</kw>
            <kw>AAL</kw>
            <kw>Sony Corporation</kw>
        </keywords>
        <abstract><p>This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs.  Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels.  The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-atrac-family-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5584</errata-url>
        <doi>10.17487/RFC5584</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5585</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Service Overview</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Email</kw>
            <kw>Electroni Mail</kw>
            <kw>Internet Mail</kw>
            <kw>Message Verification</kw>
        </keywords>
        <abstract><p>This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service.  It also describes how DKIM relates to other IETF message signature technologies.  It is intended for those who are adopting, developing, or deploying DKIM.  DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient.  The organization can be the author's, the originating sending site, an intermediary, or one of their agents.  A message can contain multiple signatures from the same or different organizations involved with the message.  DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871).  This permits verification of a responsible organization, as well as the integrity of the message contents.  DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.  DKIM's authentication of email identity can assist in the global control of "spam" and "phishing".  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-dkim-overview-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <doi>10.17487/RFC5585</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5586</doc-id>
        <title>MPLS Generic Associated Channel</title>
        <author>
            <name>M. Bocci</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Vigoureux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>mpls-tp</kw>
            <kw>oam</kw>
            <kw>g-ach</kw>
            <kw>ach</kw>
            <kw>associated channel header</kw>
            <kw>gal</kw>
            <kw>generic associated label</kw>
        </keywords>
        <abstract><p>This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires.  In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.</p></abstract>
        <draft>draft-ietf-mpls-tp-gach-gal-06</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
            <doc-id>RFC4385</doc-id>
            <doc-id>RFC5085</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6423</doc-id>
            <doc-id>RFC7026</doc-id>
            <doc-id>RFC7214</doc-id>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5586</errata-url>
        <doi>10.17487/RFC5586</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5587</doc-id>
        <title>Extended Generic Security Service Mechanism Inquiry APIs</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>mechanism</kw>
            <kw>inquiry</kw>
            <kw>extension</kw>
        </keywords>
        <abstract><p>This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.</p><p> These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-extended-mech-inquiry-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC5587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5588</doc-id>
        <title>Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>credential</kw>
            <kw>gss_store_cred</kw>
        </keywords>
        <abstract><p>This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store.  This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-gssapi-store-cred-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC5588</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5589</doc-id>
        <title>Session Initiation Protocol (SIP) Call Control - Transfer</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>A. Johnston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Petrie</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>REFER</kw>
            <kw>GRUU</kw>
            <kw>Attended Transfer</kw>
            <kw>Target-Dialog</kw>
            <kw>Out of Dialog REFER</kw>
            <kw>SIP</kw>
            <kw>SIP Services</kw>
            <kw>blind transfer</kw>
            <kw>SIP Features</kw>
            <kw>Replaces</kw>
            <kw>Referred-By</kw>
        </keywords>
        <abstract><p>This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP).  SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer.  This work is part of the SIP multiparty call control framework.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-sipping-cc-transfer-12</draft>
        <is-also>
            <doc-id>BCP0149</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5589</errata-url>
        <doi>10.17487/RFC5589</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5590</doc-id>
        <title>Transport Subsystem for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>SNMP-TRANSPORT-MIB</kw>
        </keywords>
        <abstract><p>This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411.  This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture.  As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models.  This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-tmsm-18</draft>
        <updates>
            <doc-id>RFC3411</doc-id>
            <doc-id>RFC3412</doc-id>
            <doc-id>RFC3414</doc-id>
            <doc-id>RFC3417</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0078</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <doi>10.17487/RFC5590</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5591</doc-id>
        <title>Transport Security Model for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Transport Security Model</kw>
            <kw>Security Model</kw>
        </keywords>
        <abstract><p>This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).</p><p> This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-transport-security-model-14</draft>
        <is-also>
            <doc-id>STD0078</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <doi>10.17487/RFC5591</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5592</doc-id>
        <title>Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Secure Shell</kw>
            <kw>SSH</kw>
        </keywords>
        <abstract><p>This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.</p><p> This memo also 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 monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-secshell-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <doi>10.17487/RFC5592</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5593</doc-id>
        <title>Internet Message Access Protocol (IMAP) - URL Access Identifier Extension</title>
        <author>
            <name>N. Cook</name>
        </author>
        <date>
            <month>June</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>urlauth</kw>
            <kw>imap url</kw>
        </keywords>
        <abstract><p>The existing IMAP URL specification (RFC 5092) lists several &lt;access&gt; identifiers and &lt;access&gt; identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new &lt;access&gt; identifiers as well as an IANA mechanism to register new &lt;access&gt; identifiers for future applications.</p><p> This document updates RFC 5092. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ncook-urlauth-accessid-02</draft>
        <updates>
            <doc-id>RFC5092</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5593</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5594</doc-id>
        <title>Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>A. Cooper</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>P2PI</kw>
        </keywords>
        <abstract><p>This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes.  The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA.  The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems.  Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal.  The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-p2pi-cooper-workshop-report-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5594</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5595</doc-id>
        <title>The Datagram Congestion Control Protocol (DCCP) Service Codes</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DCCP-Request Ports</kw>
        </keywords>
        <abstract><p>This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340.  It motivates the setting of a Service Code by applications.  Service Codes provide a method to identify the intended service/application to process a DCCP connection request.  This provides improved flexibility in the use and assignment of port numbers for connection multiplexing.  The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls).  This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-serv-codes-11</draft>
        <updates>
            <doc-id>RFC4340</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6335</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5595</errata-url>
        <doi>10.17487/RFC5595</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5596</doc-id>
        <title>Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>DCCP</kw>
            <kw>NAT traversal</kw>
            <kw>Middlebox Issues</kw>
        </keywords>
        <abstract><p>This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol.  The update adds support for the DCCP-Listen packet.  This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-simul-open-08</draft>
        <updates>
            <doc-id>RFC4340</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC5596</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5597</doc-id>
        <title>Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol</title>
        <author>
            <name>R. Denis-Courmont</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>dccp</kw>
        </keywords>
        <abstract><p>This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP).  These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF.  Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-behave-dccp-05</draft>
        <is-also>
            <doc-id>BCP0150</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC5597</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5598</doc-id>
        <title>Internet Mail Architecture</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>email</kw>
            <kw>e-mail</kw>
            <kw>service</kw>
            <kw>mime</kw>
            <kw>architecture</kw>
            <kw>mta</kw>
            <kw>mua</kw>
            <kw>msa</kw>
            <kw>mda</kw>
            <kw>admd</kw>
            <kw>user</kw>
            <kw>originator</kw>
            <kw>recipient</kw>
            <kw>transfer</kw>
            <kw>message transfer</kw>
            <kw>deliver</kw>
            <kw>delivery</kw>
            <kw>relay</kw>
            <kw>header</kw>
            <kw>gateway agent</kw>
            <kw>gateway actor</kw>
            <kw>gateway</kw>
            <kw>sieve</kw>
            <kw>dsn</kw>
            <kw>mdn</kw>
            <kw>tussle</kw>
            <kw>mhs</kw>
            <kw>Message handling service</kw>
            <kw>message transfer agent</kw>
            <kw>message user agent</kw>
            <kw>mail submission agent</kw>
            <kw>mail delivery agent</kw>
            <kw>administrative management domain</kw>
        </keywords>
        <abstract><p>Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service.  These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness.  To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them.  But the many differences in perspective currently make it difficult to know exactly what another participant means.  To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-crocker-email-arch-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5598</errata-url>
        <doi>10.17487/RFC5598</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5599</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5600</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5601</doc-id>
        <title>Pseudowire (PW) Management Information Base (MIB)</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Zelig</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>pseudowire edge-to-edge services</kw>
            <kw>IANA-PWE3-MIB</kw>
            <kw>PW-STD-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community.  In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-pw-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5601</errata-url>
        <doi>10.17487/RFC5601</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5602</doc-id>
        <title>Pseudowire (PW) over MPLS PSN Management Information Base (MIB)</title>
        <author>
            <name>D. Zelig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>pw operation</kw>
            <kw>PW-MPLS-STD-MIB</kw>
        </keywords>
        <abstract><p>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 MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-pw-mpls-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5602</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5603</doc-id>
        <title>Ethernet Pseudowire (PW) Management Information Base (MIB)</title>
        <author>
            <name>D. Zelig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>ethernet pw</kw>
            <kw>PW-ENET-STD-MIB</kw>
        </keywords>
        <abstract><p>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 modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-enet-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5604</doc-id>
        <title>Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)</title>
        <author>
            <name>O. Nicklass</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>pseudowire encapsulation</kw>
            <kw>t1</kw>
            <kw>e1</kw>
            <kw>t3</kw>
            <kw>e3</kw>
        </keywords>
        <abstract><p>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 pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-tdm-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5604</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5605</doc-id>
        <title>Managed Objects for ATM over Packet Switched Networks (PSNs)</title>
        <author>
            <name>O. Nicklass</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>atm pseudowire</kw>
        </keywords>
        <abstract><p>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 modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-pw-atm-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5605</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5606</doc-id>
        <title>Implications of 'retransmission-allowed' for SIP Location Conveyance</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>pidf-lo</kw>
            <kw> presence information data format for location objects</kw>
        </keywords>
        <abstract><p>This document explores an ambiguity in the interpretation of the &lt;retransmission-allowed&gt; element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.</p><p> Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-geopriv-sip-lo-retransmission-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC5606</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5607</doc-id>
        <title>Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management</title>
        <author>
            <name>D. Nelson</name>
        </author>
        <author>
            <name>G. Weber</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Device Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Network Configuration Protocol</kw>
            <kw>NETCONF</kw>
            <kw>Access Control</kw>
        </keywords>
        <abstract><p>This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS).  Both local and remote management are supported, with granular access rights and management privileges.  Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-management-authorization-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC5607</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5608</doc-id>
        <title>Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models</title>
        <author>
            <name>K. Narayan</name>
        </author>
        <author>
            <name>D. Nelson</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>authorization service</kw>
            <kw>ssh transport model</kw>
            <kw>secure shell transport model</kw>
        </keywords>
        <abstract><p>This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions.  While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-radius-usage-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5608</errata-url>
        <doi>10.17487/RFC5608</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5609</doc-id>
        <title>State Machines for the Protocol for Carrying Authentication for Network Access (PANA)</title>
        <author>
            <name>V. Fajardo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>R. Marin-Lopez</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>PANA</kw>
            <kw>State Machine</kw>
            <kw>EAP</kw>
        </keywords>
        <abstract><p>This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA).  The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine.  The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines.  The state machines and associated models are informative only.  Implementations may achieve the same results using different methods.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pana-statemachine-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pana</wg_acronym>
        <doi>10.17487/RFC5609</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5610</doc-id>
        <title>Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements</title>
        <author>
            <name>E. Boschi</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>L. Mark</name>
        </author>
        <author>
            <name>T. Zseby</name>
        </author>
        <date>
            <month>July</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>enterprise-specific Information Element</kw>
            <kw>IPFIX Template</kw>
            <kw>type record</kw>
            <kw>type options template</kw>
        </keywords>
        <abstract><p>This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream.  This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-exporting-type-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5610</errata-url>
        <doi>10.17487/RFC5610</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5611</doc-id>
        <title>Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires</title>
        <author>
            <name>A. Vainshtein</name>
        </author>
        <author>
            <name>S. Galtzur</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>l2tpv3</kw>
            <kw>layer tow tunneling protocol version 3</kw>
            <kw>structure-agnostic</kw>
            <kw>structure-aware</kw>
            <kw>cesopsn</kw>
            <kw>tdmoip</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.  Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-tdm-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC5611</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5612</doc-id>
        <title>Enterprise Number for Documentation Use</title>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>smi network management private enterprise code</kw>
        </keywords>
        <abstract><p>This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-eronen-enterprise-number-documentation-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5612</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5613</doc-id>
        <title>OSPF Link-Local Signaling</title>
        <author>
            <name>A. Zinin</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>B. Friedman</name>
        </author>
        <author>
            <name>D. Yeung</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>intra-domain routing</kw>
        </keywords>
        <abstract><p>OSPF is a link-state intra-domain routing protocol.  OSPF routers exchange information on a link using packets that follow a well-defined fixed format.  The format is not flexible enough to enable new features that need to exchange arbitrary data.  This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.  This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.</p></abstract>
        <draft>draft-ietf-ospf-lls-08</draft>
        <obsoletes>
            <doc-id>RFC4813</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC5613</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5614</doc-id>
        <title>Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding</title>
        <author>
            <name>R. Ogier</name>
        </author>
        <author>
            <name>P. Spagnolo</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>MANET routing</kw>
            <kw>link-state routing</kw>
            <kw>CDS flooding</kw>
            <kw>mesh network</kw>
            <kw>MANET Designated Router</kw>
            <kw>MDR</kw>
        </keywords>
        <abstract><p>This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs).  The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs.  OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs.  The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness.  This CDS is exploited in two ways.  First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.  Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks.  The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension.  The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states.  Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ospf-manet-mdr-05</draft>
        <updated-by>
            <doc-id>RFC7038</doc-id>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC5614</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5615</doc-id>
        <title>H.248/MEGACO Registration Procedures</title>
        <author>
            <name>C. Groves</name>
        </author>
        <author>
            <name>Y. Lin</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Package</kw>
            <kw>Error Code</kw>
            <kw>ServiceChange Reason</kw>
            <kw>Profile</kw>
        </keywords>
        <abstract><p>This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-groves-megaco-pkgereg-04</draft>
        <is-also>
            <doc-id>BCP0151</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5616</doc-id>
        <title>Streaming Internet Messaging Attachments</title>
        <author>
            <name>N. Cook</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>SIP</kw>
            <kw>streaming</kw>
            <kw>stream</kw>
            <kw>email</kw>
            <kw>multimedia</kw>
            <kw>lemonade</kw>
            <kw>attachments</kw>
            <kw>video</kw>
            <kw>audio</kw>
        </keywords>
        <abstract><p>This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.</p><p> The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-lemonade-streaming-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>lemonade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5616</errata-url>
        <doi>10.17487/RFC5616</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5617</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)</title>
        <author>
            <name>E. Allman</name>
        </author>
        <author>
            <name>J. Fenton</name>
        </author>
        <author>
            <name>M. Delany</name>
        </author>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>email</kw>
            <kw>e-mail</kw>
            <kw>rfc 5322</kw>
            <kw>rfc 5322</kw>
            <kw>rfc 822</kw>
            <kw>rfc 822</kw>
            <kw>rfc 5321</kw>
            <kw>rfc 5321</kw>
            <kw>rfc 821</kw>
            <kw>rfc 821</kw>
            <kw>rfc 4871</kw>
            <kw>rfc 4871</kw>
            <kw>DKIM</kw>
            <kw>domain keys</kw>
            <kw>domainkeys</kw>
            <kw>ADSP</kw>
            <kw>ADSP</kw>
            <kw>SSP</kw>
            <kw>architecture</kw>
            <kw>mta</kw>
            <kw>user</kw>
            <kw>delivery</kw>
            <kw>smtp</kw>
            <kw>submission</kw>
            <kw> email</kw>
            <kw>e-mail</kw>
            <kw>smtp</kw>
            <kw>Internet</kw>
            <kw>mailfrom</kw>
            <kw>mail from</kw>
            <kw>author</kw>
            <kw>return address</kw>
            <kw>sender signing</kw>
            <kw>signing practices</kw>
        </keywords>
        <abstract><p>DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages.  This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address.  It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dkim-ssp-10</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5617</errata-url>
        <doi>10.17487/RFC5617</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5618</doc-id>
        <title>Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>K. Hedayat</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>twamp-control protocol</kw>
            <kw>twamp-test protocol</kw>
            <kw>twamp modes</kw>
        </keywords>
        <abstract><p>This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol).  The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously.  The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-more-twamp-02</draft>
        <updates>
            <doc-id>RFC5357</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC5618</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5619</doc-id>
        <title>Softwire Security Analysis and Requirements</title>
        <author>
            <name>S. Yamamoto</name>
        </author>
        <author>
            <name>C. Williams</name>
        </author>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>F. Parent</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Tunnel</kw>
            <kw>Softwire</kw>
            <kw>Transition</kw>
        </keywords>
        <abstract><p>This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions.  Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-security-requirements-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5619</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5620</doc-id>
        <title>RFC Editor Model (Version 1)</title>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RFC Series Editor</kw>
            <kw>Independent Stream Editor</kw>
        </keywords>
        <abstract><p>The RFC Editor performs a number of functions that may be carried out by various persons or entities.  The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher.  It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board.  The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-rfc-editor-model-07</draft>
        <obsoleted-by>
            <doc-id>RFC6548</doc-id>
            <doc-id>RFC6635</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5620</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5621</doc-id>
        <title>Message Body Handling in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Message body</kw>
            <kw>MIME</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>This document specifies how message bodies are handled in SIP.  Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-body-handling-06</draft>
        <updates>
            <doc-id>RFC3204</doc-id>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3459</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8262</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5621</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5622</doc-id>
        <title>Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>E. Kohler</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ccid 4</kw>
            <kw>congestion control identifier 4</kw>
        </keywords>
        <abstract><p>This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP).  CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets.  CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time.  The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion.  CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-dccp-ccid4-05</draft>
        <updated-by>
            <doc-id>RFC6323</doc-id>
            <doc-id>RFC8311</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC5622</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5623</doc-id>
        <title>Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>E. Oki</name>
        </author>
        <author>
            <name>T. Takeda</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>GMPLS</kw>
            <kw>Traffic Engineering</kw>
            <kw>Label Switched Path</kw>
            <kw>Virtual Network Topology</kw>
        </keywords>
        <abstract><p>A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.</p><p> This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-inter-layer-frwk-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5623</errata-url>
        <doi>10.17487/RFC5623</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5624</doc-id>
        <title>Quality of Service Parameters for Usage with Diameter</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>QoS Parameters</kw>
        </keywords>
        <abstract><p>This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.</p><p> The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-qos-parameters-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC5624</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5625</doc-id>
        <title>DNS Proxy Implementation Guidelines</title>
        <author>
            <name>R. Bellis</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Proxy</kw>
        </keywords>
        <abstract><p>This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-dnsext-dnsproxy-06</draft>
        <is-also>
            <doc-id>BCP0152</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5625</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5626</doc-id>
        <title>Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>C. Jennings</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Mahy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Audet</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests.  However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way.  This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent.  It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-outbound-20</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3327</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5626</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5627</doc-id>
        <title>Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>NAT</kw>
            <kw>outbound</kw>
            <kw>gruu</kw>
            <kw>registration</kw>
            <kw>traversal</kw>
        </keywords>
        <abstract><p>Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance.  A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU).  This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-gruu-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5627</errata-url>
        <doi>10.17487/RFC5627</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5628</doc-id>
        <title>Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)</title>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>registration</kw>
        </keywords>
        <abstract><p>RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.</p><p> However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-gruu-reg-event-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5628</errata-url>
        <doi>10.17487/RFC5628</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5629</doc-id>
        <title>A Framework for Application Interaction in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>dtmf</kw>
        </keywords>
        <abstract><p>This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications.  By interacting with applications, users can guide the way in which they operate.  The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application.  Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams.  Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- Frequency (DTMF) input.  In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-app-interaction-framework-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5629</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5630</doc-id>
        <title>The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>F. Audet</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>SIPS</kw>
            <kw>SIP</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP).  It also makes normative changes to SIP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-sips-09</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3608</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5630</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5631</doc-id>
        <title>Session Initiation Protocol (SIP) Session Mobility</title>
        <author>
            <name>R. Shacham</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S. Thakolsri</name>
        </author>
        <author>
            <name>W. Kellerer</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>third party call control (3pcc)</kw>
            <kw>transfer</kw>
            <kw>voice over ip (voip)</kw>
        </keywords>
        <abstract><p>Session mobility is the transfer of media of an ongoing communication session from one device to another.  This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP).  Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example.  This document is an informational document.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-shacham-sipping-session-mobility-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5632</doc-id>
        <title>Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial</title>
        <author>
            <name>C. Griffiths</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>L. Popkin</name>
        </author>
        <author>
            <name>R. Woundy</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>P2P</kw>
            <kw>Peer-to-Peer</kw>
            <kw>P4P</kw>
            <kw>Proactive Network Provider Partication for P2P</kw>
            <kw>DCIA</kw>
            <kw>Distributed Computing Industry Association</kw>
        </keywords>
        <abstract><p>This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008.  This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-livingood-woundy-p4p-experiences-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5632</errata-url>
        <doi>10.17487/RFC5632</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5633</doc-id>
        <title>Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers</title>
        <author>
            <name>S. Dawkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Internet Architecture Board</kw>
            <kw>Engineering Steering Group</kw>
        </keywords>
        <abstract><p>This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-dawkins-nomcom-dont-wait-04</draft>
        <obsoleted-by>
            <doc-id>RFC7437</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3777</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5633</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5634</doc-id>
        <title>Quick-Start for the Datagram Congestion Control Protocol (DCCP)</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>A. Sathiaseelan</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>ccid</kw>
            <kw>congestion control identifier</kw>
            <kw>ccid 2</kw>
            <kw>ccid 3</kw>
            <kw>ccid 4</kw>
        </keywords>
        <abstract><p>This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP).  DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams.  DCCP is intended for applications such as streaming media, Internet telephony, and online games.  In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID).  This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4.  Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period).  The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-dccp-quickstart-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC5634</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5635</doc-id>
        <title>Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>rtbh</kw>
        </keywords>
        <abstract><p>Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks.  This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-opsec-blackhole-urpf-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC5635</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5636</doc-id>
        <title>Traceable Anonymous Certificate</title>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>H. Park</name>
        </author>
        <author>
            <name>Y. Won</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>x.509 certificate</kw>
            <kw>blind issuer</kw>
            <kw>anonymity issuer</kw>
            <kw>tacs</kw>
            <kw>end entity</kw>
            <kw>ee</kw>
        </keywords>
        <abstract><p>This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it.  The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272).  The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer).  The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs).  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pkix-tac-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5636</errata-url>
        <doi>10.17487/RFC5636</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5637</doc-id>
        <title>Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6</title>
        <author>
            <name>G. Giaretta</name>
        </author>
        <author>
            <name>I. Guardini</name>
        </author>
        <author>
            <name>E. Demaria</name>
        </author>
        <author>
            <name>J. Bournelle</name>
        </author>
        <author>
            <name>R. Lopez</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>MIPv6</kw>
            <kw>Mobile IP</kw>
        </keywords>
        <abstract><p>In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP).  In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure.  Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping.  This document describes various scenarios where a AAA interface for Mobile IPv6 is required.  Additionally, it lists design goals and requirements for such an interface.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-mext-aaa-ha-goals-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC5637</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5638</doc-id>
        <title>Simple SIP Usage Scenario for Applications in the Endpoints</title>
        <author>
            <name>H. Sinnreich</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>E. Shim</name>
        </author>
        <author>
            <name>K. Singh</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>session initiation protocol</kw>
            <kw>rich internet application</kw>
            <kw>ria</kw>
        </keywords>
        <abstract><p>For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.</p><p> This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.</p><p> References for NAT traversal and for security are also provided. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-sinnreich-sip-tools-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5638</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5639</doc-id>
        <title>Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation</title>
        <author>
            <name>M. Lochter</name>
        </author>
        <author>
            <name>J. Merkle</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications.  The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-lochter-pkix-brainpool-ecc-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5639</errata-url>
        <doi>10.17487/RFC5639</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5640</doc-id>
        <title>Load-Balancing for Mesh Softwires</title>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>bgp encapsulation subsequent address family identifier</kw>
            <kw>safi</kw>
        </keywords>
        <abstract><p>Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows.  It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network.  Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers.  Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion.  This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-lb-03</draft>
        <updated-by>
            <doc-id>RFC9012</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC5640</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5641</doc-id>
        <title>Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values</title>
        <author>
            <name>N. McGill</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>attachment circuits</kw>
            <kw>acs</kw>
            <kw>pseudowires</kw>
            <kw>pw</kw>
            <kw>active bit</kw>
            <kw>new bit</kw>
            <kw>circuit status avp</kw>
        </keywords>
        <abstract><p>This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs).  It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2tpext-circuit-status-extensions-05</draft>
        <updates>
            <doc-id>RFC3931</doc-id>
            <doc-id>RFC4349</doc-id>
            <doc-id>RFC4454</doc-id>
            <doc-id>RFC4591</doc-id>
            <doc-id>RFC4719</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC5641</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5642</doc-id>
        <title>Dynamic Hostname Exchange Mechanism for OSPF</title>
        <author>
            <name>S. Venkata</name>
        </author>
        <author>
            <name>S. Harwani</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>router information</kw>
            <kw>ri</kw>
            <kw>ospf dynamic hostname</kw>
        </keywords>
        <abstract><p>This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS.  This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-dynamic-hostname-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC5642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5643</doc-id>
        <title>Management Information Base for OSPFv3</title>
        <author>
            <name>D. Joyal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Manral</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>ipv6</kw>
            <kw>open shortest path first</kw>
            <kw>routing protocol</kw>
            <kw>OSPFV3-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.  In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-mib-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5643</errata-url>
        <doi>10.17487/RFC5643</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5644</doc-id>
        <title>IP Performance Metrics (IPPM): Spatial and Multicast</title>
        <author>
            <name>E. Stephan</name>
        </author>
        <author>
            <name>L. Liang</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>Multiple point measurement</kw>
            <kw>relative performance</kw>
            <kw>group performance statistic</kw>
            <kw>per hop measurement</kw>
            <kw>segment performance</kw>
        </keywords>
        <abstract><p>The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points.  This memo defines two new categories of metrics that extend the coverage to multiple measurement points.  It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-multimetrics-12</draft>
        <updated-by>
            <doc-id>RFC6248</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5644</errata-url>
        <doi>10.17487/RFC5644</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5645</doc-id>
        <title>Update to the Language Subtag Registry</title>
        <author>
            <name>D. Ewell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>language tags</kw>
            <kw>language tagging</kw>
            <kw>ltru</kw>
            <kw>registry</kw>
        </keywords>
        <abstract><p>This memo defines the procedure used to update the IANA Language Subtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-ltru-4645bis-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ltru</wg_acronym>
        <doi>10.17487/RFC5645</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5646</doc-id>
        <title>Tags for Identifying Languages</title>
        <author>
            <name>A. Phillips</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Davis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>language tags</kw>
            <kw>private interchange</kw>
        </keywords>
        <abstract><p>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-ietf-ltru-4646bis-23</draft>
        <obsoletes>
            <doc-id>RFC4646</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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>ltru</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5646</errata-url>
        <doi>10.17487/RFC5646</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5647</doc-id>
        <title>AES Galois Counter Mode for the Secure Shell Transport Layer Protocol</title>
        <author>
            <name>K. Igoe</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ssh</kw>
            <kw>remote-login</kw>
        </keywords>
        <abstract><p>Secure shell (SSH) is a secure remote-login protocol.  SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services.  The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-igoe-secsh-aes-gcm-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5647</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5648</doc-id>
        <title>Multiple Care-of Addresses Registration</title>
        <author>
            <name>R. Wakikawa</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>T. Ernst</name>
        </author>
        <author>
            <name>K. Nagami</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
        </keywords>
        <abstract><p>According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes.  However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses.  This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses.  The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-monami6-multiplecoa-14</draft>
        <updated-by>
            <doc-id>RFC6089</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5648</errata-url>
        <doi>10.17487/RFC5648</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5649</doc-id>
        <title>Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>M. Dworkin</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394.  This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-housley-aes-key-wrap-with-pad-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5649</errata-url>
        <doi>10.17487/RFC5649</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5650</doc-id>
        <title>Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)</title>
        <author>
            <name>M. Morgenstern</name>
        </author>
        <author>
            <name>S. Baillie</name>
        </author>
        <author>
            <name>U. Bonollo</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>218</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>adsl</kw>
            <kw>asymmetric digital subscriber line</kw>
            <kw>VDSL2-LINE-TC-MIB</kw>
            <kw>VDSL2-LINE-MIB</kw>
        </keywords>
        <abstract><p>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 parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-adslmib-vdsl2-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <doi>10.17487/RFC5650</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5651</doc-id>
        <title>Layered Coding Transport (LCT) Building Block</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>reliable multicast</kw>
        </keywords>
        <abstract><p>The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols.  LCT is specifically designed to support protocols using IP multicast, but it 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 document obsoletes RFC 3451. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-lct-revised-11</draft>
        <obsoletes>
            <doc-id>RFC3451</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5651</errata-url>
        <doi>10.17487/RFC5651</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5652</doc-id>
        <title>Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>digital signature</kw>
            <kw>message content</kw>
        </keywords>
        <abstract><p>This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-rfc3852bis-00</draft>
        <obsoletes>
            <doc-id>RFC3852</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8933</doc-id>
            <doc-id>RFC9629</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0070</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5652</errata-url>
        <doi>10.17487/RFC5652</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5653</doc-id>
        <title>Generic Security Service API Version 2: Java Bindings Update</title>
        <author>
            <name>M. Upadhyay</name>
        </author>
        <author>
            <name>S. Malkani</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <keywords>
            <kw>gssapi</kw>
            <kw>application program interface</kw>
            <kw>gss-api</kw>
            <kw>GSI</kw>
        </keywords>
        <abstract><p>The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings" (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.</p><p> The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-rfc2853bis-05</draft>
        <obsoletes>
            <doc-id>RFC2853</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8353</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC5653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5654</doc-id>
        <title>Requirements of an MPLS Transport Profile</title>
        <author>
            <name>B. Niven-Jenkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Brungard</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Betts</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Sprecher</name>
        </author>
        <author>
            <name>S. Ueno</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>MPLS-TP</kw>
            <kw>ITU</kw>
            <kw>ITU-T</kw>
        </keywords>
        <abstract><p>This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).</p><p> This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.</p><p> The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-requirements-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5654</errata-url>
        <doi>10.17487/RFC5654</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5655</doc-id>
        <title>Specification of the IP Flow Information Export (IPFIX) File Format</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>E. Boschi</name>
        </author>
        <author>
            <name>L. Mark</name>
        </author>
        <author>
            <name>T. Zseby</name>
        </author>
        <author>
            <name>A. Wagner</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>flow file</kw>
            <kw>flow storage</kw>
            <kw>ipfix storage</kw>
            <kw>netflow storage</kw>
        </keywords>
        <abstract><p>This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol.  It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages.  This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-file-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5655</errata-url>
        <doi>10.17487/RFC5655</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5656</doc-id>
        <title>Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer</title>
        <author>
            <name>D. Stebila</name>
        </author>
        <author>
            <name>J. Green</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Key Agreement</kw>
            <kw>Cryptography</kw>
        </keywords>
        <abstract><p>This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol.  In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-green-secsh-ecc-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5656</errata-url>
        <doi>10.17487/RFC5656</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5657</doc-id>
        <title>Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard</title>
        <author>
            <name>L. Dusseault</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>rfc2026</kw>
            <kw>2026</kw>
            <kw>guidance</kw>
            <kw>interoperation</kw>
            <kw>implementation</kw>
            <kw>reports</kw>
            <kw>advancement</kw>
            <kw>draft standard</kw>
        </keywords>
        <abstract><p>Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol.  Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers.  This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-dusseault-impl-reports-04</draft>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5657</errata-url>
        <doi>10.17487/RFC5657</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5658</doc-id>
        <title>Addressing Record-Route Issues in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>T. Froment</name>
        </author>
        <author>
            <name>C. Lebel</name>
        </author>
        <author>
            <name>B. Bonnaerens</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>multi-homed</kw>
            <kw>user agent</kw>
            <kw>proxy</kw>
            <kw>interoperability</kw>
            <kw>double record-routing</kw>
        </keywords>
        <abstract><p>A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it.  This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy.  These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp".  When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s).  It is not possible to make one header have the characteristics of both interfaces at the same time.  This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-record-route-fix-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5658</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5659</doc-id>
        <title>An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge</title>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>psn</kw>
            <kw>packet switched network</kw>
        </keywords>
        <abstract><p>This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments.  Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN.  It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pwe3-ms-pw-arch-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5659</errata-url>
        <doi>10.17487/RFC5659</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5660</doc-id>
        <title>IPsec Channels: Connection Latching</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>connection latching</kw>
            <kw>channel</kw>
        </keywords>
        <abstract><p>This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.</p><p> Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.</p><p> Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-btns-connection-latching-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>btns</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5660</errata-url>
        <doi>10.17487/RFC5660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5661</doc-id>
        <title>Network File System (NFS) Version 4 Minor Version 1 Protocol</title>
        <author>
            <name>S. Shepler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Eisler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Noveck</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>617</page-count>
        <keywords>
            <kw>Access Control List</kw>
            <kw>ACL</kw>
            <kw>Communications Sessions</kw>
            <kw>Exactly Once Semantics</kw>
            <kw>File Access Protocol</kw>
            <kw>Global Namespace</kw>
            <kw>Network Authentication</kw>
            <kw>Network File Access</kw>
            <kw>Network File System</kw>
            <kw>Network Security</kw>
            <kw>NFS</kw>
            <kw>Parallel Storage</kw>
            <kw>pNFS</kw>
            <kw>Storage Cluster</kw>
        </keywords>
        <abstract><p>This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently.  Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS).  NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol.  Thus, this document neither updates nor obsoletes RFC 3530.  NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0.  Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-minorversion1-29</draft>
        <obsoleted-by>
            <doc-id>RFC8881</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8178</doc-id>
            <doc-id>RFC8434</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5661</errata-url>
        <doi>10.17487/RFC5661</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5662</doc-id>
        <title>Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description</title>
        <author>
            <name>S. Shepler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Eisler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Noveck</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>xdr</kw>
            <kw>nfsv4</kw>
        </keywords>
        <abstract><p>This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-minorversion1-dot-x-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5662</errata-url>
        <doi>10.17487/RFC5662</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5663</doc-id>
        <title>Parallel NFS (pNFS) Block/Volume Layout</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>S. Fridella</name>
        </author>
        <author>
            <name>J. Glasgow</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>nfsv4</kw>
            <kw>network file sharing version 4</kw>
        </keywords>
        <abstract><p>Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server.  This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used.  The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-pnfs-block-12</draft>
        <updated-by>
            <doc-id>RFC6688</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5663</errata-url>
        <doi>10.17487/RFC5663</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5664</doc-id>
        <title>Object-Based Parallel NFS (pNFS) Operations</title>
        <author>
            <name>B. Halevy</name>
        </author>
        <author>
            <name>B. Welch</name>
        </author>
        <author>
            <name>J. Zelenka</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>OSD</kw>
            <kw>storage device</kw>
        </keywords>
        <abstract><p>Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server.  This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a.  the Layout Type.  The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification.  This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-pnfs-obj-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5664</errata-url>
        <doi>10.17487/RFC5664</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5665</doc-id>
        <title>IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats</title>
        <author>
            <name>M. Eisler</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>rpcbind</kw>
            <kw>portmap</kw>
            <kw>transport independent remote procedure call</kw>
            <kw>TI-RPC</kw>
            <kw>transport identifier</kw>
            <kw>protocol identifier</kw>
        </keywords>
        <abstract><p>This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs).  This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-rpc-netid-06</draft>
        <updates>
            <doc-id>RFC1833</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5665</errata-url>
        <doi>10.17487/RFC5665</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5666</doc-id>
        <title>Remote Direct Memory Access Transport for Remote Procedure Call</title>
        <author>
            <name>T. Talpey</name>
        </author>
        <author>
            <name>B. Callaghan</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Network File System</kw>
            <kw>NFS</kw>
            <kw>ONC RPC</kw>
            <kw>RDMA</kw>
            <kw>RDDP</kw>
            <kw>iWARP</kw>
            <kw>InfiniBand</kw>
        </keywords>
        <abstract><p>This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC).  The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-rpcrdma-09</draft>
        <obsoleted-by>
            <doc-id>RFC8166</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC5666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5667</doc-id>
        <title>Network File System (NFS) Direct Data Placement</title>
        <author>
            <name>T. Talpey</name>
        </author>
        <author>
            <name>B. Callaghan</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Network File System</kw>
            <kw>NFS</kw>
            <kw>ONC RPC</kw>
            <kw>RDMA</kw>
            <kw>RDDP</kw>
            <kw>iWARP</kw>
            <kw>InfiniBand</kw>
        </keywords>
        <abstract><p>This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol.  It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-nfsdirect-08</draft>
        <obsoleted-by>
            <doc-id>RFC8267</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC5667</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5668</doc-id>
        <title>4-Octet AS Specific BGP Extended Community</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>S. Sangli</name>
        </author>
        <author>
            <name>D. Tappan</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>autonomous system</kw>
        </keywords>
        <abstract><p>This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-as4octet-ext-community-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC5668</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5669</doc-id>
        <title>The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)</title>
        <author>
            <name>S. Yoon</name>
        </author>
        <author>
            <name>J. Kim</name>
        </author>
        <author>
            <name>H. Park</name>
        </author>
        <author>
            <name>H. Jeong</name>
        </author>
        <author>
            <name>Y. Won</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-seed-srtp-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5669</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5670</doc-id>
        <title>Metering and Marking Behaviour of PCN-Nodes</title>
        <author>
            <name>P. Eardley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>pre-congestion notification</kw>
            <kw>threshold metering</kw>
            <kw>threshold marking</kw>
            <kw>pcn-threshold-rate</kw>
            <kw>pcn-excess-rate</kw>
        </keywords>
        <abstract><p>The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion.  This document defines the two metering and marking behaviours of PCN-nodes.  Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate").  Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate").  The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pcn-marking-behaviour-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5670</errata-url>
        <doi>10.17487/RFC5670</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5671</doc-id>
        <title>Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)</title>
        <author>
            <name>S. Yasukawa</name>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>generalized mpls</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</p><p> Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).</p><p> This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-p2mp-app-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC5671</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5672</doc-id>
        <title>RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update</title>
        <author>
            <name>D. Crocker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>email</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>spam</kw>
            <kw>abuse</kw>
            <kw>errata</kw>
            <kw>trust</kw>
            <kw>Signing Domain Identifier</kw>
            <kw>SDID</kw>
            <kw>AUID</kw>
            <kw>Agent or User Identifier</kw>
        </keywords>
        <abstract><p>This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures".  Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.  The Update is in the style of an Errata entry, albeit a rather long one. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dkim-rfc4871-errata-07</draft>
        <obsoleted-by>
            <doc-id>RFC6376</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4871</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <doi>10.17487/RFC5672</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5673</doc-id>
        <title>Industrial Routing Requirements in Low-Power and Lossy Networks</title>
        <author>
            <name>K. Pister</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Dwars</name>
        </author>
        <author>
            <name>T. Phinney</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>lln</kw>
        </keywords>
        <abstract><p>The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations.  The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-roll-indus-routing-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC5673</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5674</doc-id>
        <title>Alarms in Syslog</title>
        <author>
            <name>S. Chisholm</name>
        </author>
        <author>
            <name>R. Gerhards</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>SYSLOG</kw>
            <kw>alarm</kw>
        </keywords>
        <abstract><p>This document describes how to send alarm information in syslog.  It includes the mapping of ITU perceived severities onto syslog message fields.  It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opsawg-syslog-alarm-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC5674</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5675</doc-id>
        <title>Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages</title>
        <author>
            <name>V. Marinov</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Notifications</kw>
            <kw>Syslog</kw>
        </keywords>
        <abstract><p>This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opsawg-syslog-snmp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC5675</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5676</doc-id>
        <title>Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>A. Karmakar</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Notifications</kw>
            <kw>Syslog</kw>
        </keywords>
        <abstract><p>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 mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opsawg-syslog-msg-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5676</errata-url>
        <doi>10.17487/RFC5676</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5677</doc-id>
        <title>IEEE 802.21 Mobility Services Framework Design (MSFD)</title>
        <author>
            <name>T. Melia</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bajko</name>
        </author>
        <author>
            <name>S. Das</name>
        </author>
        <author>
            <name>N. Golmie</name>
        </author>
        <author>
            <name>JC. Zuniga</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>media independent handover</kw>
            <kw>mih</kw>
            <kw>mobility services</kw>
            <kw>mos</kw>
        </keywords>
        <abstract><p>This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages.  The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages.  This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server.  Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-mstp-solution-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5677</errata-url>
        <doi>10.17487/RFC5677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5678</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery</title>
        <author>
            <name>G. Bajko</name>
        </author>
        <author>
            <name>S. Das</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>handover preparation handover decision</kw>
            <kw>media independent handover services</kw>
        </keywords>
        <abstract><p>This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677).  These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection).  The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-mos-dhcp-options-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5678</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5679</doc-id>
        <title>Locating IEEE 802.21 Mobility Services Using DNS</title>
        <author>
            <name>G. Bajko</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>domain name server</kw>
            <kw>handover preparation</kw>
            <kw>handover decision</kw>
            <kw>media independent handover services</kw>
        </keywords>
        <abstract><p>This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services.  Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection).  The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-mos-dns-discovery-07</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5679</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5680</doc-id>
        <title>The Nominating Committee Process: Open Disclosure of Willing Nominees</title>
        <author>
            <name>S. Dawkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p></abstract>
        <draft>draft-dawkins-nomcom-openlist-06</draft>
        <obsoleted-by>
            <doc-id>RFC7437</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3777</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5681</doc-id>
        <title>TCP Congestion Control</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>E. Blanton</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>slow start</kw>
            <kw>congestion avoidance</kw>
            <kw>fast retransmit</kw>
            <kw>fast recovery</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 2581. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-rfc2581bis-07</draft>
        <obsoletes>
            <doc-id>RFC2581</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9438</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5681</errata-url>
        <doi>10.17487/RFC5681</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5682</doc-id>
        <title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP</title>
        <author>
            <name>P. Sarolahti</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <author>
            <name>K. Yamamoto</name>
        </author>
        <author>
            <name>M. Hata</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SACK</kw>
            <kw>transmission control protocol</kw>
            <kw>loss recovery</kw>
        </keywords>
        <abstract><p>The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.</p><p> Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-rfc4138bis-04</draft>
        <updates>
            <doc-id>RFC4138</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC5682</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5683</doc-id>
        <title>Password-Authenticated Key (PAK) Diffie-Hellman Exchange</title>
        <author>
            <name>A. Brusilovsky</name>
        </author>
        <author>
            <name>I. Faynberg</name>
        </author>
        <author>
            <name>Z. Zeltsan</name>
        </author>
        <author>
            <name>S. Patel</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.</p><p> The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-brusilovsky-pak-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5683</errata-url>
        <doi>10.17487/RFC5683</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5684</doc-id>
        <title>Unintended Consequences of NAT Deployments with Overlapping Address Space</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>B. Ford</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>network address translator</kw>
        </keywords>
        <abstract><p>This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices.  First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces.  Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks.  This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ford-behave-top-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5684</errata-url>
        <doi>10.17487/RFC5684</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5685</doc-id>
        <title>Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>K. Weniger</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IKEv2 Redirect</kw>
            <kw>REDIRECT</kw>
            <kw>REDIRECTED_FROM</kw>
            <kw>anycast redirect</kw>
            <kw>home agent redirect</kw>
            <kw>VPN gateway direct</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway.  This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway.  The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-redirect-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC5685</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5686</doc-id>
        <title>RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec</title>
        <author>
            <name>Y. Hiwasaki</name>
        </author>
        <author>
            <name>H. Ohmuro</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RTP Payload type</kw>
            <kw>MIME</kw>
            <kw>UEMCLIP</kw>
            <kw>PCMU</kw>
            <kw>Speech Coding</kw>
        </keywords>
        <abstract><p>This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711.  The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-uemclip-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5686</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5687</doc-id>
        <title>GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Location Information</kw>
            <kw>Location Information Server</kw>
            <kw>Location by Value</kw>
            <kw>Location by Reference</kw>
        </keywords>
        <abstract><p>This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP).  This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network.  The obtained location information can then be used for a variety of different protocols and purposes.  For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-geopriv-l7-lcp-ps-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC5687</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5688</doc-id>
        <title>A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>IMS</kw>
        </keywords>
        <abstract><p>The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities.  Similarly, a specification exists to allow a UA to indicate its capabilities in a registration.  Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types.  The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability.  This specification allows a UA to indicate which application subtypes the agent supports. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-rosenberg-sip-app-media-tag-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5688</errata-url>
        <doi>10.17487/RFC5688</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5689</doc-id>
        <title>Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>September</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>webdav</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-webdav-mkcol-06</draft>
        <updates>
            <doc-id>RFC4791</doc-id>
            <doc-id>RFC4918</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <doi>10.17487/RFC5689</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5690</doc-id>
        <title>Adding Acknowledgement Congestion Control to TCP</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>A. Arcia</name>
        </author>
        <author>
            <name>D. Ros</name>
        </author>
        <author>
            <name>J. Iyengar</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>ackcc</kw>
        </keywords>
        <abstract><p>This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP.  The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver.  The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender.  The TCP data receiver sends roughly one ACK packet for every R data packets received.  This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2.  This acknowledgement congestion control mechanism is being specified for further evaluation by the network community.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-floyd-tcpm-ackcc-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5690</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5691</doc-id>
        <title>RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio</title>
        <author>
            <name>F. de Bont</name>
        </author>
        <author>
            <name>S. Doehla</name>
        </author>
        <author>
            <name>M. Schmidt</name>
        </author>
        <author>
            <name>R. Sperschneider</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MPEG Surround</kw>
            <kw>RFC 3640</kw>
            <kw>RTP</kw>
            <kw>MPEG-4</kw>
            <kw>AAC</kw>
        </keywords>
        <abstract><p>This memo describes extensions for the RTP payload format defined in RFC 3640 for the transport of MPEG Surround multi-channel audio.  Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream.  In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-mps-03</draft>
        <updates>
            <doc-id>RFC3640</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5691</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5692</doc-id>
        <title>Transmission of IP over Ethernet over IEEE 802.16 Networks</title>
        <author>
            <name>H. Jeon</name>
        </author>
        <author>
            <name>S. Jeong</name>
        </author>
        <author>
            <name>M. Riegel</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Bridge</kw>
            <kw>WiMAX</kw>
            <kw>Ethernet-CS</kw>
            <kw>Cellular</kw>
        </keywords>
        <abstract><p>This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology.  The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations.  Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>16ng</wg_acronym>
        <doi>10.17487/RFC5692</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5693</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Problem Statement</title>
        <author>
            <name>J. Seedorf</name>
        </author>
        <author>
            <name>E. Burger</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>peer-to-peer</kw>
            <kw>p2p</kw>
        </keywords>
        <abstract><p>Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.</p><p> This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-alto-problem-statement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC5693</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5694</doc-id>
        <title>Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability</title>
        <author>
            <name>G. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>P2P</kw>
            <kw>decentralized</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>In this document, we provide a survey of P2P (Peer-to-Peer) systems.  The survey includes a definition and several taxonomies of P2P systems.  This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet.  Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-p2p-archs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5694</errata-url>
        <doi>10.17487/RFC5694</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5695</doc-id>
        <title>MPLS Forwarding Benchmarking Methodology for IP Flows</title>
        <author>
            <name>A. Akhter</name>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpmls forwarding devices</kw>
        </keywords>
        <abstract><p>This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows.  It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts.  This document seeks to extend these efforts to the MPLS paradigm.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-bmwg-mpls-forwarding-meth-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5695</errata-url>
        <doi>10.17487/RFC5695</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5696</doc-id>
        <title>Baseline Encoding and Transport of Pre-Congestion Information</title>
        <author>
            <name>T. Moncaster</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Differentiated Services</kw>
            <kw>Admission Control</kw>
            <kw>Codepoint</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.  It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain.  These marks can then be evaluated to determine how close the domain is to being congested.  This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains.  The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked.  Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pcn-baseline-encoding-07</draft>
        <obsoleted-by>
            <doc-id>RFC6660</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5696</errata-url>
        <doi>10.17487/RFC5696</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5697</doc-id>
        <title>Other Certificates Extension</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>template</kw>
        </keywords>
        <abstract><p>Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information.  This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.  This memo defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pkix-other-certs-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC5697</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5698</doc-id>
        <title>Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)</title>
        <author>
            <name>T. Kunz</name>
        </author>
        <author>
            <name>S. Okunick</name>
        </author>
        <author>
            <name>U. Pordesch</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>long term archive</kw>
            <kw>security</kw>
            <kw>policy</kw>
            <kw>hash algorithm</kw>
            <kw>public key algorithm</kw>
        </keywords>
        <abstract><p>Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability.  When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered.  This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ltans-dssc-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ltans</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5698</errata-url>
        <doi>10.17487/RFC5698</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5699</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5700</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5701</doc-id>
        <title>IPv6 Address Specific BGP Extended Community Attribute</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community.  The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment.  This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem.  The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-v6-ext-communities-02</draft>
        <updated-by>
            <doc-id>RFC7153</doc-id>
            <doc-id>RFC7606</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC5701</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5702</doc-id>
        <title>Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC</title>
        <author>
            <name>J. Jansen</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>RSA</kw>
            <kw>SHA-256</kw>
            <kw>SHA-512</kw>
        </keywords>
        <abstract><p>This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-rsasha256-14</draft>
        <updated-by>
            <doc-id>RFC6944</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5702</errata-url>
        <doi>10.17487/RFC5702</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5703</doc-id>
        <title>Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Email</kw>
            <kw>Electronic Mail</kw>
            <kw>Internet Mail</kw>
            <kw>Message Filtering</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-mime-loop-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5703</errata-url>
        <doi>10.17487/RFC5703</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5704</doc-id>
        <title>Uncoordinated Protocol Development Considered Harmful</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Morrow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ITU-T</kw>
            <kw>MPLS-TP</kw>
            <kw>T-MPLS</kw>
            <kw>Joint working team</kw>
            <kw>JWT</kw>
        </keywords>
        <abstract><p>This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.</p><p> This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.</p><p> Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.</p></abstract>
        <draft>draft-iab-mpls-tp-uncoord-harmful-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5704</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5705</doc-id>
        <title>Keying Material Exporters for Transport Layer Security (TLS)</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>key establishment</kw>
        </keywords>
        <abstract><p>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism for allowing that. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-extractor-07</draft>
        <updated-by>
            <doc-id>RFC8446</doc-id>
            <doc-id>RFC8447</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5705</errata-url>
        <doi>10.17487/RFC5705</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5706</doc-id>
        <title>Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>November</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>management</kw>
            <kw>operations</kw>
        </keywords>
        <abstract><p>New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols.  Retrofitting operations and management is sub-optimal.  The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-ietf-opsawg-operations-and-management-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5706</errata-url>
        <doi>10.17487/RFC5706</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5707</doc-id>
        <title>Media Server Markup Language (MSML)</title>
        <author>
            <name>A. Saleem</name>
        </author>
        <author>
            <name>Y. Xin</name>
        </author>
        <author>
            <name>G. Sharratt</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>184</page-count>
        <abstract><p>The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers.  The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry.  Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users.  MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams.  As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences.  Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML.  MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-saleem-msml-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5707</errata-url>
        <doi>10.17487/RFC5707</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5708</doc-id>
        <title>X.509 Key and Signature Encoding for the KeyNote Trust Management System</title>
        <author>
            <name>A. Keromytis</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.</p><p> In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-keromytis-keynote-x509-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5708</errata-url>
        <doi>10.17487/RFC5708</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5709</doc-id>
        <title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>M. Fanto</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>October</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>nist</kw>
            <kw>secure  hash standard</kw>
            <kw>hashed message authentication code</kw>
        </keywords>
        <abstract><p>This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism.  This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-hmac-sha-07</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7474</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5709</errata-url>
        <doi>10.17487/RFC5709</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5710</doc-id>
        <title>PathErr Message Triggered MPLS and GMPLS LSP Reroutes</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>resource reservation protocol</kw>
            <kw>rsvp</kw>
            <kw>multiprotocol label switching</kw>
            <kw>generalized mpls</kw>
            <kw>rsvp-te</kw>
        </keywords>
        <abstract><p>This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources.  Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown.  This document describes the usage of existing Standards Track mechanisms to support LSP rerouting.  In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed.  While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-gmpls-lsp-reroute-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5710</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5711</doc-id>
        <title>Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>rsvp-te</kw>
        </keywords>
        <abstract><p>The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-3209-patherr-06</draft>
        <updates>
            <doc-id>RFC3209</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5711</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5712</doc-id>
        <title>MPLS Traffic Engineering Soft Preemption</title>
        <author>
            <name>M. Meyer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpls-te</kw>
            <kw>te lsp</kw>
        </keywords>
        <abstract><p>This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs).  Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption.  The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP.  For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted.  For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-soft-preemption-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5712</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5713</doc-id>
        <title>Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)</title>
        <author>
            <name>H. Moustafa</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>S. De Cnodder</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ANCP security</kw>
            <kw>ANCP threats</kw>
            <kw>ANCP attacks</kw>
        </keywords>
        <abstract><p>The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.</p><p> This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ancp-security-threats-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ancp</wg_acronym>
        <doi>10.17487/RFC5713</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5714</doc-id>
        <title>IP Fast Reroute Framework</title>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IP Fast Reroute</kw>
            <kw>MPLS Fast Reroute</kw>
            <kw>Routing Convergence</kw>
            <kw>Network  Topology</kw>
            <kw>loop-free-convergence</kw>
        </keywords>
        <abstract><p>This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths.  Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-rtgwg-ipfrr-framework-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC5714</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5715</doc-id>
        <title>A Framework for Loop-Free Convergence</title>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IP Fast Reroute</kw>
            <kw>MPLS Fast Reroute</kw>
            <kw>Routing Convergence</kw>
            <kw>Network Topology</kw>
            <kw>PLSN</kw>
            <kw>not-via</kw>
            <kw>Incremental Cost</kw>
            <kw>Packet Marking</kw>
            <kw>ordered fib</kw>
            <kw>ofib</kw>
        </keywords>
        <abstract><p>A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.</p><p> This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-rtgwg-lf-conv-frmwk-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC5715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5716</doc-id>
        <title>Requirements for Federated File Systems</title>
        <author>
            <name>J. Lentini</name>
        </author>
        <author>
            <name>C. Everhart</name>
        </author>
        <author>
            <name>D. Ellard</name>
        </author>
        <author>
            <name>R. Tewari</name>
        </author>
        <author>
            <name>M. Naik</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Federated File Systems</kw>
            <kw>Federated FA</kw>
            <kw>FedFS</kw>
            <kw>Fed-FS</kw>
            <kw>Federation</kw>
        </keywords>
        <abstract><p>This document describes and lists the functional requirements of a federated file system and defines related terms.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-nfsv4-federated-fs-reqts-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC5716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5717</doc-id>
        <title>Partial Lock Remote Procedure Call (RPC) for NETCONF</title>
        <author>
            <name>B. Lengyel</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract><p>The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores.  In some situations, a way to lock only parts of a configuration datastore is required.  This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-partial-lock-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5717</errata-url>
        <doi>10.17487/RFC5717</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5718</doc-id>
        <title>An In-Band Data Communication Network For the MPLS Transport Profile</title>
        <author>
            <name>D. Beller</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MPLS-TP</kw>
            <kw>DCN</kw>
            <kw>SCN</kw>
            <kw>MCN</kw>
            <kw>G-Ach</kw>
            <kw>GAL</kw>
        </keywords>
        <abstract><p>The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.</p><p> The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.</p><p> This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-gach-dcn-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5719</doc-id>
        <title>Updated IANA Considerations for Diameter Command Code Allocations</title>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>diameter application</kw>
            <kw>diameter commands</kw>
        </keywords>
        <abstract><p>The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.</p><p> This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-diameter-cmd-iana-01</draft>
        <obsoleted-by>
            <doc-id>RFC6733</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3588</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC5719</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5720</doc-id>
        <title>Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)</title>
        <author>
            <name>F. Templin</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>enterprise network</kw>
        </keywords>
        <abstract><p>RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion.  The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself.  Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security.  These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches.  The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-templin-ranger-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5720</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5721</doc-id>
        <title>POP3 Support for UTF-8</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>POP</kw>
            <kw>UTF8</kw>
            <kw>mail</kw>
            <kw>email</kw>
            <kw>internationalization</kw>
            <kw>charset</kw>
        </keywords>
        <abstract><p>This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-pop-09</draft>
        <obsoleted-by>
            <doc-id>RFC6856</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC5721</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5722</doc-id>
        <title>Handling of Overlapping IPv6 Fragments</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>fragmentation</kw>
            <kw>overlapping fragments</kw>
        </keywords>
        <abstract><p>The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap.  This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-overlap-fragment-03</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6946</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5722</errata-url>
        <doi>10.17487/RFC5722</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5723</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>Internet Key Exchange</kw>
            <kw>session resumption</kw>
            <kw>failover</kw>
            <kw>high availability</kw>
            <kw>cryptographic ticket</kw>
            <kw>cryptographic token</kw>
            <kw>stateful resumption</kw>
            <kw>stateless resumption</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.</p><p> To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.</p><p> In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.</p><p> A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-resumption-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC5723</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5724</doc-id>
        <title>URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <author>
            <name>A. Vaha-Sipila</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>GSM</kw>
            <kw>SMS</kw>
            <kw>URI scheme</kw>
        </keywords>
        <abstract><p>This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message.  SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-wilde-sms-uri-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5724</errata-url>
        <doi>10.17487/RFC5724</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5725</doc-id>
        <title>Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>D. Hsu</name>
        </author>
        <author>
            <name>M. Lague</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Loss repair</kw>
            <kw>retransmission</kw>
            <kw>FEC</kw>
        </keywords>
        <abstract><p>This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs).  One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block.  This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report.  The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied.  By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion.  This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-post-repair-rtcp-xr-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5725</errata-url>
        <doi>10.17487/RFC5725</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5726</doc-id>
        <title>Mobile IPv6 Location Privacy Solutions</title>
        <author>
            <name>Y. Qiu</name>
        </author>
        <author>
            <name>F. Zhao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>mobopts</kw>
        </keywords>
        <abstract><p>Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet.  However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets.  In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-mobopts-location-privacy-solutions-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5726</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5727</doc-id>
        <title>Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>RAI</kw>
            <kw>sipping</kw>
        </keywords>
        <abstract><p>This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area.  As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP.  This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space.  This document obsoletes RFC 3427.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-peterson-rai-rfc3427bis-04</draft>
        <obsoletes>
            <doc-id>RFC3427</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3265</doc-id>
            <doc-id>RFC3969</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7957</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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5727</errata-url>
        <doi>10.17487/RFC5727</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5728</doc-id>
        <title>The SatLabs Group DVB-RCS MIB</title>
        <author>
            <name>S. Combes</name>
        </author>
        <author>
            <name>P. Amundsen</name>
        </author>
        <author>
            <name>M. Lambert</name>
        </author>
        <author>
            <name>H-P. Lexow</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>digital video broadcasting return channel</kw>
            <kw>DVB-RCS-MIB</kw>
        </keywords>
        <abstract><p>This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group.  It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-combes-ipdvb-mib-rcs-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5728</errata-url>
        <doi>10.17487/RFC5728</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5729</doc-id>
        <title>Clarifications on the Routing of Diameter Requests Based on the Username and the Realm</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>L. Morand</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>nai</kw>
            <kw>network access identifier</kw>
            <kw>decorated</kw>
            <kw>multi-realm</kw>
        </keywords>
        <abstract><p>This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms.  These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-nai-routing-04</draft>
        <updates>
            <doc-id>RFC3588</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC5729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5730</doc-id>
        <title>Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>shared framework mapping</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 4930. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-rfc4930bis-02</draft>
        <obsoletes>
            <doc-id>RFC4930</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0069</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5730</errata-url>
        <doi>10.17487/RFC5730</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5731</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Domain Name Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>Extensible Provisioning Protocol</kw>
            <kw>XML</kw>
            <kw>domain</kw>
            <kw>domain name</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 4931. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-rfc4931bis-01</draft>
        <obsoletes>
            <doc-id>RFC4931</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0069</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5731</errata-url>
        <doi>10.17487/RFC5731</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5732</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Host Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>Extensible Provisioning Protocol</kw>
            <kw>XML</kw>
            <kw>host</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 4932. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-rfc4932bis-01</draft>
        <obsoletes>
            <doc-id>RFC4932</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0069</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5732</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5733</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Contact Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>Extensible Provisioning Protocol</kw>
            <kw>XML</kw>
            <kw>contact</kw>
            <kw>registrant</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 4933. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-rfc4933bis-02</draft>
        <obsoletes>
            <doc-id>RFC4933</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0069</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5734</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Transport over TCP</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>August</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>Extensible Provisioning Protocol</kw>
            <kw>XML</kw>
            <kw>TCP</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 4934. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hollenbeck-rfc4934bis-01</draft>
        <obsoletes>
            <doc-id>RFC4934</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0069</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5734</errata-url>
        <doi>10.17487/RFC5734</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5735</doc-id>
        <title>Special Use IPv4 Addresses</title>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>space assignments</kw>
        </keywords>
        <abstract><p>This document obsoletes RFC 3330.  It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA).  It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries.  It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-iana-rfc3330bis-11</draft>
        <obsoletes>
            <doc-id>RFC3330</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6890</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6598</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5735</errata-url>
        <doi>10.17487/RFC5735</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5736</doc-id>
        <title>IANA IPv4 Special Purpose Address Registry</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iana-special-ipv4-registry-02</draft>
        <obsoleted-by>
            <doc-id>RFC6890</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5737</doc-id>
        <title>IPv4 Address Blocks Reserved for Documentation</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>example addresses</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract><p>Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents.  This document describes the use of these blocks.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iana-ipv4-examples-02</draft>
        <updates>
            <doc-id>RFC1166</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5738</doc-id>
        <title>IMAP Support for UTF-8</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>internet message access protocol</kw>
            <kw>imap4rev1</kw>
        </keywords>
        <abstract><p>This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-imap-utf8-09</draft>
        <obsoleted-by>
            <doc-id>RFC6855</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5738</errata-url>
        <doi>10.17487/RFC5738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5739</doc-id>
        <title>IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>C. Madson</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>remote vpn access</kw>
            <kw>vpn gateway</kw>
            <kw>virtual link</kw>
        </keywords>
        <abstract><p>When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads.  The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6.  This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link".  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-ipv6-config-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5739</errata-url>
        <doi>10.17487/RFC5739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5740</doc-id>
        <title>NACK-Oriented Reliable Multicast (NORM) Transport 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>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>reliable multicast</kw>
            <kw>transport</kw>
            <kw>negative-acknowledgment</kw>
            <kw>forward error correction</kw>
            <kw>packet erasure coding</kw>
            <kw>group communication</kw>
        </keywords>
        <abstract><p>This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.  This protocol can 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 (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design.  This document obsoletes RFC 3940. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-pi-norm-revised-14</draft>
        <obsoletes>
            <doc-id>RFC3940</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5740</errata-url>
        <doi>10.17487/RFC5740</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5741</doc-id>
        <title>RFC Streams, Headers, and Boilerplates</title>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.  This document describes them and introduces some updates to reflect current usage and requirements of RFC publication.  In particular, this updated structure is intended to communicate clearly the source of RFC creation and review.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-streams-headers-boilerplates-08</draft>
        <obsoleted-by>
            <doc-id>RFC7841</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2223</doc-id>
            <doc-id>RFC4844</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5741</errata-url>
        <doi>10.17487/RFC5741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5742</doc-id>
        <title>IESG Procedures for Handling of Independent and IRTF Stream Submissions</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.</p><p> This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-housley-iesg-rfc3932bis-12</draft>
        <obsoletes>
            <doc-id>RFC3932</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2026</doc-id>
            <doc-id>RFC3710</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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5742</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5743</doc-id>
        <title>Definition of an Internet Research Task Force (IRTF) Document Stream</title>
        <author>
            <name>A. Falk</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>irtf stream</kw>
        </keywords>
        <abstract><p>This memo defines the publication stream for RFCs from the Internet Research Task Force.  Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-rfcs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5743</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5744</doc-id>
        <title>Procedures for Rights Handling in the RFC Independent Submission Stream</title>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>incoming rights</kw>
            <kw>outgoing rights</kw>
            <kw>ietf trust</kw>
        </keywords>
        <abstract><p>This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text.  It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-braden-independent-submission-02</draft>
        <updates>
            <doc-id>RFC4846</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5745</doc-id>
        <title>Procedures for Rights Handling in the RFC IAB Stream</title>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>December</month>
            <year>2009</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>incoming rights</kw>
            <kw>outgoing rights</kw>
            <kw>ietf trust</kw>
        </keywords>
        <abstract><p>This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text.  It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.  This memo provides information for the Internet community.</p></abstract>
        <draft>draft-malis-iab-stream-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5746</doc-id>
        <title>Transport Layer Security (TLS) Renegotiation Indication Extension</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>M. Ray</name>
        </author>
        <author>
            <name>S. Dispensa</name>
        </author>
        <author>
            <name>N. Oskov</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ssl</kw>
            <kw>secure socket layer</kw>
        </keywords>
        <abstract><p>Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client.  The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.  This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-renegotiation-03</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC4366</doc-id>
            <doc-id>RFC4347</doc-id>
            <doc-id>RFC4346</doc-id>
            <doc-id>RFC2246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC5746</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5747</doc-id>
        <title>4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions</title>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>M. Xu</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPv4/IPv6</kw>
            <kw>coexistence</kw>
            <kw>CNGI</kw>
            <kw>CERNET2</kw>
            <kw>Softwire mesh</kw>
        </keywords>
        <abstract><p>The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired.  This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP.  It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels.  The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-wu-softwire-4over6-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5747</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5748</doc-id>
        <title>IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>S. Yoon</name>
        </author>
        <author>
            <name>J. Jeong</name>
        </author>
        <author>
            <name>H. Kim</name>
        </author>
        <author>
            <name>H. Jeong</name>
        </author>
        <author>
            <name>Y. Won</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-seokung-msec-mikey-seed-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5748</errata-url>
        <doi>10.17487/RFC5748</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5749</doc-id>
        <title>Distribution of EAP-Based Keys for Handover and Re-Authentication</title>
        <author>
            <name>K. Hoeper</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nakhjiri</name>
        </author>
        <author>
            <name>Y. Ohba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>mobility</kw>
            <kw>EAP</kw>
            <kw>key management</kw>
            <kw>key distribution</kw>
        </keywords>
        <abstract><p>This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer.  The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer.  This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements.  The described protocol template does not specify message formats, data encoding, or other implementation details.  It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hokey-key-mgm-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5749</errata-url>
        <doi>10.17487/RFC5749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5750</doc-id>
        <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling</title>
        <author>
            <name>B. Ramsdell</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail </kw>
            <kw>extensions</kw>
            <kw>secure</kw>
        </keywords>
        <abstract><p>This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 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 5280, 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 5280.  This document obsoletes RFC 3850. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-3850bis-11</draft>
        <obsoletes>
            <doc-id>RFC3850</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8550</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <doi>10.17487/RFC5750</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5751</doc-id>
        <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</title>
        <author>
            <name>B. Ramsdell</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2.  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 3851. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-3851bis-11</draft>
        <obsoletes>
            <doc-id>RFC3851</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8551</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5751</errata-url>
        <doi>10.17487/RFC5751</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5752</doc-id>
        <title>Multiple Signatures in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>signeddata</kw>
            <kw>signerinfo</kw>
            <kw>downgrade attacks</kw>
            <kw>algorithm migration</kw>
        </keywords>
        <abstract><p>Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information.  SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures.  If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s).  This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks.  Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-multisig-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5752</errata-url>
        <doi>10.17487/RFC5752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5753</doc-id>
        <title>Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>public key</kw>
            <kw>digital signatures</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>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 NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards.  This document obsoletes RFC 3278.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-smime-3278bis-09</draft>
        <obsoletes>
            <doc-id>RFC3278</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5753</errata-url>
        <doi>10.17487/RFC5753</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5754</doc-id>
        <title>Using SHA2 Algorithms with Cryptographic Message Syntax</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>secure hash algorithm</kw>
            <kw>message digest algorithm</kw>
            <kw>sha-224</kw>
            <kw>sha-256</kw>
            <kw>sha-384</kw>
            <kw>sha-512</kw>
            <kw>cms</kw>
            <kw>dsa</kw>
            <kw>digital signature algorithm</kw>
            <kw>rsa</kw>
            <kw>rivest sharmi adleman</kw>
            <kw>ecdsa</kw>
            <kw>elliptic curve dsa</kw>
            <kw>smimecapabilities</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS).  It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms.  Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-smime-sha2-11</draft>
        <updates>
            <doc-id>RFC3370</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5754</errata-url>
        <doi>10.17487/RFC5754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5755</doc-id>
        <title>An Internet Attribute Certificate Profile for Authorization</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>electronic mail</kw>
            <kw>email</kw>
            <kw>ipsec</kw>
            <kw>www security</kw>
        </keywords>
        <abstract><p>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.  This document obsoletes RFC 3281. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-3281update-05</draft>
        <obsoletes>
            <doc-id>RFC3281</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5755</errata-url>
        <doi>10.17487/RFC5755</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5756</doc-id>
        <title>Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <author>
            <name>K. Yiu</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>rsa encryption scheme</kw>
            <kw>optical asymmetric encryption padding</kw>
            <kw>subjectpublickeyinfo</kw>
        </keywords>
        <abstract><p>This document updates RFC 4055.  It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc4055-update-02</draft>
        <updates>
            <doc-id>RFC4055</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5756</errata-url>
        <doi>10.17487/RFC5756</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5757</doc-id>
        <title>Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey</title>
        <author>
            <name>T. Schmidt</name>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>PMIPv6</kw>
            <kw>FMIPv6</kw>
            <kw>HMIPv6</kw>
            <kw>SSM</kw>
            <kw>ASM</kw>
            <kw>MLD</kw>
            <kw>Mobile Multicast Routing</kw>
            <kw>Hybrid Multicast</kw>
            <kw>Wireless</kw>
            <kw>Multipoint</kw>
        </keywords>
        <abstract><p>This document discusses current mobility extensions to IP-layer multicast.  It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast.  Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized.  Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain.  It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space.  This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers.  This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-mobopts-mmcastv6-ps-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5758</doc-id>
        <title>Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA</title>
        <author>
            <name>Q. Dang</name>
        </author>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>K. Moriarty</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>digital signature algorithm</kw>
            <kw>elliptic curve digital signature algorithm</kw>
            <kw>pki</kw>
        </keywords>
        <abstract><p>This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm.  This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs).  This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-sha2-dsa-ecdsa-10</draft>
        <updates>
            <doc-id>RFC3279</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5758</errata-url>
        <doi>10.17487/RFC5758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5759</doc-id>
        <title>Suite B Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>J. Solinas</name>
        </author>
        <author>
            <name>L. Zieglar</name>
        </author>
        <date>
            <month>January</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>x.509 v3 certificates</kw>
            <kw>x.509 v2 certificate revocation lists</kw>
            <kw>crl</kw>
        </keywords>
        <abstract><p>This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography.  The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-solinas-suiteb-cert-profile-04</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5759</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5760</doc-id>
        <title>RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>J. Chesterfield</name>
        </author>
        <author>
            <name>E. Schooler</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>ssm</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender.  The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired.  In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtcpssm-19</draft>
        <updated-by>
            <doc-id>RFC6128</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5760</errata-url>
        <doi>10.17487/RFC5760</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5761</doc-id>
        <title>Multiplexing RTP Data and Control Packets on a Single Port</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port.  It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-and-rtcp-mux-07</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
            <doc-id>RFC3551</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8035</doc-id>
            <doc-id>RFC8858</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5761</errata-url>
        <doi>10.17487/RFC5761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5762</doc-id>
        <title>RTP and the Datagram Congestion Control Protocol (DCCP)</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks.  The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications.  This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-rtp-07</draft>
        <updated-by>
            <doc-id>RFC6773</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC5762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5763</doc-id>
        <title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>J. Fischl</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>stip</kw>
            <kw>session initiation protocol</kw>
            <kw>fingerprint attribute</kw>
            <kw>dtls handshake</kw>
        </keywords>
        <abstract><p>This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-dtls-srtp-framework-07</draft>
        <updated-by>
            <doc-id>RFC8842</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5763</errata-url>
        <doi>10.17487/RFC5763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5764</doc-id>
        <title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>secure rtp control protocol</kw>
            <kw>srtcp</kw>
        </keywords>
        <abstract><p>This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-dtls-srtp-07</draft>
        <updated-by>
            <doc-id>RFC7983</doc-id>
            <doc-id>RFC9443</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5764</errata-url>
        <doi>10.17487/RFC5764</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5765</doc-id>
        <title>Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>E. Marocco</name>
        </author>
        <author>
            <name>E. Ivov</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>p2p</kw>
            <kw>overlay</kw>
            <kw>rtc</kw>
            <kw>voip</kw>
        </keywords>
        <abstract><p>Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues.  It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P.  Such a migration needs to address a new set of P2P-specific security problems.  This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication.  This document is a product of the P2P Research Group.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-p2prg-rtc-security-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5765</errata-url>
        <doi>10.17487/RFC5765</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5766</doc-id>
        <title>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>TURN</kw>
            <kw>STUN</kw>
            <kw>ICE</kw>
        </keywords>
        <abstract><p>If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers).  In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay.  This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.  TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-turn-16</draft>
        <obsoleted-by>
            <doc-id>RFC8656</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8155</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5766</errata-url>
        <doi>10.17487/RFC5766</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5767</doc-id>
        <title>User-Agent-Driven Privacy Mechanism for SIP</title>
        <author>
            <name>M. Munakata</name>
        </author>
        <author>
            <name>S. Schubert</name>
        </author>
        <author>
            <name>T. Ohba</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>IMS</kw>
            <kw>privacy</kw>
            <kw>guidelines</kw>
        </keywords>
        <abstract><p>This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sip-ua-privacy-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5768</doc-id>
        <title>Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>NAT</kw>
        </keywords>
        <abstract><p>This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP).  The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE.  The option tag allows a UA to require support for ICE in order for a call to proceed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-ice-option-tag-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5768</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5769</doc-id>
        <title>Test Vectors for Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>R. Denis-Courmont</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>STUN</kw>
            <kw>test</kw>
            <kw>vectors</kw>
            <kw>fingerprint</kw>
        </keywords>
        <abstract><p>The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes.  The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor).  This document provides test vectors for those attributes.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-behave-stun-test-vectors-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5769</errata-url>
        <doi>10.17487/RFC5769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5770</doc-id>
        <title>Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators</title>
        <author>
            <name>M. Komu</name>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Melen</name>
        </author>
        <author>
            <name>A. Keranen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>ICE</kw>
            <kw>HIP relay</kw>
        </keywords>
        <abstract><p>This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal.  The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP).  This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server.  With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-nat-traversal-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC5770</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5771</doc-id>
        <title>IANA Guidelines for IPv4 Multicast Address Assignments</title>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>protocol</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract><p>This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses.  It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-mboned-rfc3171bis-08</draft>
        <obsoletes>
            <doc-id>RFC3138</doc-id>
            <doc-id>RFC3171</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2780</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0051</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5771</errata-url>
        <doi>10.17487/RFC5771</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5772</doc-id>
        <title>A Set of Possible Requirements for a Future Routing Architecture</title>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>Routing Research Group</kw>
            <kw>RRG</kw>
            <kw>IDR</kw>
            <kw>FDR</kw>
        </keywords>
        <abstract><p>The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.</p><p> The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-irtf-routing-reqs-11</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC5772</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5773</doc-id>
        <title>Analysis of Inter-Domain Routing Requirements and History</title>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>A. Doria</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>History</kw>
            <kw>IRTF</kw>
            <kw>Routing Research Group</kw>
            <kw>RRG</kw>
            <kw>Routing Requirements</kw>
            <kw>IDR</kw>
            <kw>FDR</kw>
        </keywords>
        <abstract><p>This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing.  The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006.  It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols.  This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties.  The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.  This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-irtf-routing-history-10</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5773</errata-url>
        <doi>10.17487/RFC5773</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5774</doc-id>
        <title>Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition</title>
        <author>
            <name>K. Wolf</name>
        </author>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776.  Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-geopriv-civic-address-recommendations-03</draft>
        <updates>
            <doc-id>RFC4776</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0154</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5774</errata-url>
        <doi>10.17487/RFC5774</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5775</doc-id>
        <title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Forward Error Correction</kw>
            <kw>FEC</kw>
            <kw>Layered Coding Transport</kw>
            <kw>LCT</kw>
            <kw>Building Block</kw>
            <kw>WEBRC</kw>
            <kw>reliable +object delivery</kw>
            <kw>reliable file delivery</kw>
            <kw>broadcast</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>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 document obsoletes RFC 3450. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-pi-alc-revised-10</draft>
        <obsoletes>
            <doc-id>RFC3450</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC5775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5776</doc-id>
        <title>Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>A. Francillon</name>
        </author>
        <author>
            <name>S. Faurite</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>TESLA</kw>
            <kw>FLUTE</kw>
            <kw>ALC</kw>
            <kw>NORM</kw>
        </keywords>
        <abstract><p>This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols.  This document only considers the authentication/integrity verification of the packets generated by the session's sender.  The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-msec-tesla-for-alc-norm-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5776</errata-url>
        <doi>10.17487/RFC5776</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5777</doc-id>
        <title>Traffic Classification and Quality of Service (QoS) Attributes for Diameter</title>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>M. Arumaithurai</name>
        </author>
        <author>
            <name>M. Jones</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>Qos Attributes</kw>
            <kw>Traffic classification</kw>
            <kw>Filtering</kw>
            <kw>Firewalling</kw>
        </keywords>
        <abstract><p>This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment.  These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-qos-attributes-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5777</errata-url>
        <doi>10.17487/RFC5777</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5778</doc-id>
        <title>Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Bournelle</name>
        </author>
        <author>
            <name>G. Giaretta</name>
        </author>
        <author>
            <name>M. Nakhjiri</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
        </keywords>
        <abstract><p>Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.</p><p> This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-mip6-split-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5778</errata-url>
        <doi>10.17487/RFC5778</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5779</doc-id>
        <title>Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Bournelle</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>A. Muhanna</name>
        </author>
        <author>
            <name>U. Meyer</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>aaa</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>and accounting</kw>
        </keywords>
        <abstract><p>This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain.  These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-pmip6-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC5779</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5780</doc-id>
        <title>NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>D. MacDonald</name>
        </author>
        <author>
            <name>B. Lowekamp</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>NAT type diagnostics</kw>
        </keywords>
        <abstract><p>This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-behave-nat-behavior-discovery-08</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5780</errata-url>
        <doi>10.17487/RFC5780</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5781</doc-id>
        <title>The rsync URI Scheme</title>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>rsyncuri</kw>
        </keywords>
        <abstract><p>This document specifies the rsync Uniform Resource Identifier (URI) scheme.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-weiler-rsync-uri-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5781</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5782</doc-id>
        <title>DNS Blacklists and Whitelists</title>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>mail</kw>
            <kw>electronic mail</kw>
            <kw>DNS</kw>
            <kw>spam</kw>
            <kw>blacklist</kw>
            <kw>whitelist</kw>
        </keywords>
        <abstract><p>The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains.  The DNS has become the de-facto standard method of distributing these blacklists and whitelists.  This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-asrg-dnsbl-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5782</errata-url>
        <doi>10.17487/RFC5782</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5783</doc-id>
        <title>Congestion Control in the RFC Series</title>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>W. Eddy</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document is an informational snapshot taken by the IRTF\'s Internet Congestion Control Research Group (ICCRG) in October 2008.  It provides a survey of congestion control topics described by documents in the RFC series.  This does not modify or update the specifications or status of the RFC documents that are discussed.  It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-iccrg-cc-rfcs-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5783</errata-url>
        <doi>10.17487/RFC5783</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5784</doc-id>
        <title>Sieve Email Filtering:  Sieves and Display Directives in XML</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>S. Vedam</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>ESMTP</kw>
            <kw>Sieve</kw>
        </keywords>
        <abstract><p>This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.</p><p> The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-freed-sieve-in-xml-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5784</errata-url>
        <doi>10.17487/RFC5784</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5785</doc-id>
        <title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>E. Hammer-Lahav</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>well-known locations</kw>
        </keywords>
        <abstract><p>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-nottingham-site-meta-05</draft>
        <obsoleted-by>
            <doc-id>RFC8615</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2616</doc-id>
            <doc-id>RFC2818</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5785</errata-url>
        <doi>10.17487/RFC5785</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5786</doc-id>
        <title>Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions</title>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
        </keywords>
        <abstract><p>OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.</p><p> In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.</p><p> This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-te-node-addr-07</draft>
        <updates>
            <doc-id>RFC3630</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6827</doc-id>
            <doc-id>RFC8687</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5786</errata-url>
        <doi>10.17487/RFC5786</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5787</doc-id>
        <title>OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing</title>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>itu-t</kw>
            <kw>ospfv2 link state routing protocol</kw>
        </keywords>
        <abstract><p>The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).</p><p> The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks.</p><p> The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.</p><p> Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ason-routing-ospf-09</draft>
        <obsoleted-by>
            <doc-id>RFC6827</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5787</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5788</doc-id>
        <title>IMAP4 Keyword Registry</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>D. Cridland</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>email</kw>
            <kw>tag</kw>
            <kw>label</kw>
            <kw>keyword</kw>
        </keywords>
        <abstract><p>The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]</p></abstract>
        <draft>draft-melnikov-imap-keywords-10</draft>
        <updated-by>
            <doc-id>RFC8621</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5788</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5789</doc-id>
        <title>PATCH Method for HTTP</title>
        <author>
            <name>L. Dusseault</name>
        </author>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>PATCH</kw>
            <kw>Hypertext Transfer Protocol</kw>
        </keywords>
        <abstract><p>Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification.  The existing HTTP PUT method only allows a complete replacement of a document.  This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-dusseault-http-patch-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5789</errata-url>
        <doi>10.17487/RFC5789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5790</doc-id>
        <title>Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols</title>
        <author>
            <name>H. Liu</name>
        </author>
        <author>
            <name>W. Cao</name>
        </author>
        <author>
            <name>H. Asaeda</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IGMP</kw>
            <kw>MLD</kw>
            <kw>Lite</kw>
            <kw>lightweight</kw>
        </keywords>
        <abstract><p>This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2.  The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mboned-lightweight-igmpv3-mldv2-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC5790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5791</doc-id>
        <title>RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <author>
            <name>J. Kunze</name>
        </author>
        <date>
            <month>February</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>DCMI</kw>
            <kw>Dublin Core Metadata Initiative</kw>
            <kw>XHTML</kw>
            <kw>HTML</kw>
            <kw>metadata</kw>
        </keywords>
        <abstract><p>This document obsoletes RFC 2731, "Encoding Dublin Core Metadata in HTML", as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-reschke-rfc2731bis-05</draft>
        <obsoletes>
            <doc-id>RFC2731</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5791</errata-url>
        <doi>10.17487/RFC5791</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5792</doc-id>
        <title>PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)</title>
        <author>
            <name>P. Sangster</name>
        </author>
        <author>
            <name>K. Narayan</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol.  The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nea-pa-tnc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>nea</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5792</errata-url>
        <doi>10.17487/RFC5792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5793</doc-id>
        <title>PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)</title>
        <author>
            <name>R. Sahita</name>
        </author>
        <author>
            <name>S. Hanna</name>
        </author>
        <author>
            <name>R. Hurst</name>
        </author>
        <author>
            <name>K. Narayan</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>NEA</kw>
            <kw>Network Endpoint Assessment</kw>
        </keywords>
        <abstract><p>This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol.  The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nea-pb-tnc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>nea</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5793</errata-url>
        <doi>10.17487/RFC5793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5794</doc-id>
        <title>A Description of the ARIA Encryption Algorithm</title>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>J. Kim</name>
        </author>
        <author>
            <name>D. Kwon</name>
        </author>
        <author>
            <name>C. Kim</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ARIA</kw>
            <kw>encryption</kw>
            <kw>block</kw>
            <kw>cipher</kw>
        </keywords>
        <abstract><p>This document describes the ARIA encryption algorithm.  ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys.  The algorithm consists of a key scheduling part and data randomizing part.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-nsri-aria-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5794</errata-url>
        <doi>10.17487/RFC5794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5795</doc-id>
        <title>The RObust Header Compression (ROHC) Framework</title>
        <author>
            <name>K. Sandlund</name>
        </author>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.</p><p> The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.</p><p> This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-rfc4995bis-03</draft>
        <obsoletes>
            <doc-id>RFC4995</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5795</errata-url>
        <doi>10.17487/RFC5795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5796</doc-id>
        <title>Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages</title>
        <author>
            <name>W. Atwood</name>
        </author>
        <author>
            <name>S. Islam</name>
        </author>
        <author>
            <name>M. Siami</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>security</kw>
            <kw>PIM-SM</kw>
            <kw>routing security</kw>
            <kw>multicast routing</kw>
            <kw>link-local message</kw>
            <kw>Protocol Independent Multicast Sparse Mode</kw>
        </keywords>
        <abstract><p>RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol.  This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH).  It specifies optional mechanisms to provide confidentiality using the ESP.  Manual keying is specified as the mandatory and default group key management solution.  To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided.  However, the procedures for implementing automated group key management are left to other documents.  This document updates RFC 4601. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-sm-linklocal-10</draft>
        <updates>
            <doc-id>RFC4601</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC5796</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5797</doc-id>
        <title>FTP Command and Extension Registry</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>A. Hoenes</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>FTP FEAT command</kw>
            <kw>FTP FEAT response</kw>
        </keywords>
        <abstract><p>Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959.  RFC 2389 established a mechanism for specifying and negotiating FTP extensions.  The number of extensions, both those supported by the mechanism and some that are not, continues to increase.  An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity.  This specification establishes that registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-klensin-ftp-registry-04</draft>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5797</errata-url>
        <doi>10.17487/RFC5797</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5798</doc-id>
        <title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6</title>
        <author>
            <name>S. Nadas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6.  It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6".  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 IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses.  VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol.  Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap.  The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable.  For IPv4, 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.  For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vrrp-unified-spec-05</draft>
        <obsoletes>
            <doc-id>RFC3768</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9568</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>vrrp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5798</errata-url>
        <doi>10.17487/RFC5798</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5799</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5800</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5801</doc-id>
        <title>Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework.  This is done by defining a new SASL mechanism family, called GS2.  This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding.  Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sasl-gs2-20</draft>
        <updated-by>
            <doc-id>RFC9266</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5801</errata-url>
        <doi>10.17487/RFC5801</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5802</doc-id>
        <title>Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms</title>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>A. Menon-Sen</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>simple authentication and security layer</kw>
        </keywords>
        <abstract><p>The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.</p><p> This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sasl-scram-11</draft>
        <updated-by>
            <doc-id>RFC7677</doc-id>
            <doc-id>RFC9266</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sasl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5802</errata-url>
        <doi>10.17487/RFC5802</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5803</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>authpassword</kw>
            <kw>simple authentication and security layer</kw>
            <kw>sasl</kw>
        </keywords>
        <abstract><p>This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-melnikov-sasl-scram-ldap-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5803</errata-url>
        <doi>10.17487/RFC5803</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5804</doc-id>
        <title>A Protocol for Remotely Managing Sieve Scripts</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Martin</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>managesieve</kw>
        </keywords>
        <abstract><p>Sieve scripts allow users to filter incoming email.  Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them.  This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server.  This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-sieve-managesieve-09</draft>
        <updated-by>
            <doc-id>RFC7817</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5804</errata-url>
        <doi>10.17487/RFC5804</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5805</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Transactions</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>acid</kw>
            <kw>atomic consistency isolation durability</kw>
        </keywords>
        <abstract><p>Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties.  Each of these update operations act upon an entry.  It is often desirable to update two or more entries in a single unit of interaction, a transaction.  Transactions are necessary to support a number of applications including resource provisioning.  This document extends LDAP to support transactions.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-zeilenga-ldap-txn-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5805</errata-url>
        <doi>10.17487/RFC5805</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5806</doc-id>
        <title>Diversion Indication in SIP</title>
        <author>
            <name>S. Levy</name>
        </author>
        <author>
            <name>M. Mohali</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.</p><p> This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.</p><p> This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-levy-sip-diversion-11</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5806</errata-url>
        <doi>10.17487/RFC5806</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5807</doc-id>
        <title>Definition of Master Key between PANA Client and Enforcement Point</title>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>protocol for carrying authentication for network access</kw>
        </keywords>
        <abstract><p>This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering.  The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication.  The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ohba-pana-pemk-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5807</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5808</doc-id>
        <title>Requirements for a Location-by-Reference Mechanism</title>
        <author>
            <name>R. Marshall</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-geopriv-lbyr-requirements-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC5808</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5809</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5810</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Protocol Specification</title>
        <author>
            <name>A. Doria</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Hadi Salim</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Haas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Khosravi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Wang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Dong</name>
        </author>
        <author>
            <name>R. Gopal</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>control elements</kw>
            <kw>forwarding elements</kw>
            <kw>fe</kw>
            <kw>ce</kw>
            <kw>network element</kw>
            <kw>ne</kw>
            <kw>tml</kw>
            <kw>transport mapping layer</kw>
        </keywords>
        <abstract><p>This document specifies the Forwarding and Control Element Separation (ForCES) protocol.  The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE).  This specification is intended to meet the ForCES protocol requirements defined in RFC 3654.  Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-forces-protocol-22</draft>
        <updated-by>
            <doc-id>RFC7121</doc-id>
            <doc-id>RFC7391</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5810</errata-url>
        <doi>10.17487/RFC5810</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5811</doc-id>
        <title>SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol</title>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <author>
            <name>K. Ogawa</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>TML</kw>
            <kw>stream conrol transmission protocol</kw>
        </keywords>
        <abstract><p>This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol.  It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-forces-sctptml-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC5811</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5812</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Forwarding Element Model</title>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>134</page-count>
        <keywords>
            <kw>forwarding element</kw>
            <kw>control element</kw>
        </keywords>
        <abstract><p>This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol.  The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly.  More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected.  This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-forces-model-16</draft>
        <updated-by>
            <doc-id>RFC7408</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5812</errata-url>
        <doi>10.17487/RFC5812</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5813</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) MIB</title>
        <author>
            <name>R. Haas</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>network element</kw>
            <kw>ne</kw>
            <kw>forces-mib</kw>
        </keywords>
        <abstract><p>This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community.  In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-forces-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC5813</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5814</doc-id>
        <title>Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks</title>
        <author>
            <name>W. Sun</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zhang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Signaling performance</kw>
            <kw>RSVP-TE delay measurement</kw>
            <kw>control plane performance</kw>
        </keywords>
        <abstract><p>Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.</p><p> This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lsp-dppm-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5814</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5815</doc-id>
        <title>Definitions of Managed Objects for IP Flow Information Export</title>
        <author>
            <name>T. Dietz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Kobayashi</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>G. Muenz</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>Selector</kw>
            <kw>Collector</kw>
            <kw>Exporter</kw>
            <kw>Sampling</kw>
            <kw>Filtering</kw>
            <kw>IPFIX</kw>
            <kw>IPFIX-MIB</kw>
            <kw>IPFIX-SELECTOR-MIB</kw>
        </keywords>
        <abstract><p>This document defines managed objects for IP Flow Information eXport (IPFIX).  These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-mib-10</draft>
        <obsoleted-by>
            <doc-id>RFC6615</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5815</errata-url>
        <doi>10.17487/RFC5815</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5816</doc-id>
        <title>ESSCertIDv2 Update for RFC 3161</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>N. Pope</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>signer certificate</kw>
            <kw>secure hash algorithm</kw>
            <kw>sha-1</kw>
        </keywords>
        <abstract><p>This document updates RFC 3161.  It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc3161-update-09</draft>
        <updates>
            <doc-id>RFC3161</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC5816</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5817</doc-id>
        <title>Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks</title>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>A. Zamfir</name>
        </author>
        <author>
            <name>J. Newton</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>mpls-te</kw>
            <kw>te</kw>
        </keywords>
        <abstract><p>MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.</p><p> This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ccamp-mpls-graceful-shutdown-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5817</errata-url>
        <doi>10.17487/RFC5817</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5818</doc-id>
        <title>Data Channel Status Confirmation Extensions for the Link Management Protocol</title>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>H. Xu</name>
        </author>
        <author>
            <name>S. Bardalai</name>
        </author>
        <author>
            <name>J. Meuric</name>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>LMP</kw>
        </keywords>
        <abstract><p>This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found.  As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-confirm-data-channel-status-09</draft>
        <updated-by>
            <doc-id>RFC6898</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5819</doc-id>
        <title>IMAP4 Extension for Returning STATUS Information in Extended LIST</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>T. Sirainen</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>list</kw>
            <kw>lsub</kw>
        </keywords>
        <abstract><p>Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes.  In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found.  This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-morg-status-in-list-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>morg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5819</errata-url>
        <doi>10.17487/RFC5819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5820</doc-id>
        <title>Extensions to OSPF to Support Mobile Ad Hoc Networking</title>
        <author>
            <name>A. Roy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Chandra</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>manet</kw>
            <kw>ospf-or</kw>
            <kw>ospf-overlapping relay</kw>
            <kw>link-local signaling</kw>
            <kw>lls</kw>
            <kw>ospf-manet</kw>
        </keywords>
        <abstract><p>This document describes extensions to OSPF to support mobile ad hoc networks (MANETs).  The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates.  OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-manet-or-03</draft>
        <updated-by>
            <doc-id>RFC7137</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC5820</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5821</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5822</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5823</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5824</doc-id>
        <title>Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN</title>
        <author>
            <name>K. Kumaki</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>Y. Kamite</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>triple-play service</kw>
        </keywords>
        <abstract><p>Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.</p><p> Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-l3vpn-e2e-rsvp-te-reqts-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC5824</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5825</doc-id>
        <title>Displaying Downgraded Messages for Email Address Internationalization</title>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>Email Address Internationalization</kw>
            <kw>Downgrade</kw>
            <kw>MAIL</kw>
        </keywords>
        <abstract><p>This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-downgraded-display-03</draft>
        <obsoleted-by>
            <doc-id>RFC6530</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC5825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5826</doc-id>
        <title>Home Automation Routing Requirements in Low-Power and Lossy Networks</title>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>J. Buron</name>
        </author>
        <author>
            <name>G. Porcu</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>roll</kw>
            <kw>routing over low power and lossy</kw>
        </keywords>
        <abstract><p>This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks.  In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes.  Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control).  Because such devices only cover a limited radio range, routing is often required.  The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-roll-home-routing-reqs-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5826</errata-url>
        <doi>10.17487/RFC5826</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5827</doc-id>
        <title>Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>K. Avrachenkov</name>
        </author>
        <author>
            <name>U. Ayesta</name>
        </author>
        <author>
            <name>J. Blanton</name>
        </author>
        <author>
            <name>P. Hurtig</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>fast retransmission</kw>
        </keywords>
        <abstract><p>This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small.  The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission.  This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-early-rexmt-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC5827</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5828</doc-id>
        <title>Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework</title>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>transport networks</kw>
        </keywords>
        <abstract><p>There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models.  As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM).  This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity.  GMPLS has already been specified for similar technologies.  Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ethernet-arch-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5828</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5829</doc-id>
        <title>Link Relation Types for Simple Version Navigation between Web Resources</title>
        <author>
            <name>A. Brown</name>
        </author>
        <author>
            <name>G. Clemm</name>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-brown-versioning-link-relations-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5829</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5830</doc-id>
        <title>GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>russian federal standard</kw>
            <kw>electronic encryption</kw>
            <kw>decryption</kw>
            <kw>message authentication</kw>
            <kw>russian cryptographic standard</kw>
        </keywords>
        <abstract><p>This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-dolmatov-cryptocom-gost2814789-08</draft>
        <updated-by>
            <doc-id>RFC8891</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5830</errata-url>
        <doi>10.17487/RFC5830</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5831</doc-id>
        <title>GOST R 34.11-94: Hash Function Algorithm</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>russian federal standard</kw>
            <kw>russian cryptographic standard</kw>
            <kw>russian cryptography</kw>
        </keywords>
        <abstract><p>This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-dolmatov-cryptocom-gost341194-07</draft>
        <updated-by>
            <doc-id>RFC6986</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5831</errata-url>
        <doi>10.17487/RFC5831</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5832</doc-id>
        <title>GOST R 34.10-2001: Digital Signature Algorithm</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>russian federal standard</kw>
            <kw>digital signature</kw>
            <kw>russian cryptographic standard</kw>
            <kw>russian cryptography</kw>
        </keywords>
        <abstract><p>This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.</p></abstract>
        <draft>draft-dolmatov-cryptocom-gost34102001-08</draft>
        <updated-by>
            <doc-id>RFC7091</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5832</errata-url>
        <doi>10.17487/RFC5832</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5833</doc-id>
        <title>Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB</title>
        <author>
            <name>Y. Shi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Perkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Elliott</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Zhang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>CAPWAP-BASE-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol.  This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-capwap-base-mib-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC5833</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5834</doc-id>
        <title>Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11</title>
        <author>
            <name>Y. Shi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Perkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Elliott</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Zhang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>CAPWAP-DOT11-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding.  This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-capwap-802dot11-mib-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>capwap</wg_acronym>
        <doi>10.17487/RFC5834</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5835</doc-id>
        <title>Framework for Metric Composition</title>
        <author>
            <name>A. Morton</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Van den Berghe</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF.  This new framework memo describes the generic composition and aggregation mechanisms.  The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ippm-framework-compagg-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC5835</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5836</doc-id>
        <title>Extensible Authentication Protocol (EAP) Early Authentication Problem Statement</title>
        <author>
            <name>Y. Ohba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>eap early authentication</kw>
        </keywords>
        <abstract><p>Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival.  This document discusses the EAP early authentication problem in detail.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-hokey-preauth-ps-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <doi>10.17487/RFC5836</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5837</doc-id>
        <title>Extending ICMP for Interface and Next-Hop Identification</title>
        <author>
            <name>A. Atlas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Bonica</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>JR. Rivers</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Internet Control Message Protocol</kw>
        </keywords>
        <abstract><p>This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.</p><p> Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-atlas-icmp-unnumbered-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5837</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5838</doc-id>
        <title>Support of Address Families in OSPFv3</title>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Mirtorabi</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>af</kw>
            <kw>instance id</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances.  It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header.  This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-af-alt-10</draft>
        <updated-by>
            <doc-id>RFC6969</doc-id>
            <doc-id>RFC7949</doc-id>
            <doc-id>RFC8362</doc-id>
            <doc-id>RFC9454</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5838</errata-url>
        <doi>10.17487/RFC5838</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5839</doc-id>
        <title>An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification</title>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>D. Willis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SIP events</kw>
            <kw>subnot-etags</kw>
            <kw>optimization</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents.  This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state.  These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent.  This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received.  When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-subnot-etags-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC5839</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5840</doc-id>
        <title>Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility</title>
        <author>
            <name>K. Grewal</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>wesp</kw>
        </keywords>
        <abstract><p>This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions.  Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet.  This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop).  The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-traffic-visibility-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC5840</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5841</doc-id>
        <title>TCP Option to Denote Packet Mood</title>
        <author>
            <name>R. Hay</name>
        </author>
        <author>
            <name>W. Turkal</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document proposes a new TCP option to denote packet mood.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-1april2010-tcp-option-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5841</errata-url>
        <doi>10.17487/RFC5841</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5842</doc-id>
        <title>Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)</title>
        <author>
            <name>G. Clemm</name>
        </author>
        <author>
            <name>J. Crawford</name>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Whitehead</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>WebDAV</kw>
            <kw>collections</kw>
            <kw>hard link</kw>
        </keywords>
        <abstract><p>This specification defines bindings, and the BIND method for creating multiple bindings to the same resource.  Creating a new binding to a resource causes at least one new URI to be mapped to that resource.  Servers are required to ensure the integrity of any bindings that they allow to be created.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-webdav-bind-27</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5842</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5843</doc-id>
        <title>Additional Hash Algorithms for HTTP Instance Digests</title>
        <author>
            <name>A. Bryan</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>Digest Algorithm Values registry update</kw>
        </keywords>
        <abstract><p>The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" defines values for digest algorithms used by Instance Digests in HTTP.  Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource.  This document adds new values to the registry and updates previous values.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-bryan-http-digest-algorithm-values-update-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5843</errata-url>
        <doi>10.17487/RFC5843</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5844</doc-id>
        <title>IPv4 Support for Proxy Mobile IPv6</title>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>NAT traversal</kw>
            <kw>Dual Stack</kw>
            <kw>Mobility</kw>
            <kw>IPv4 Support</kw>
            <kw>IPv4 Support for PMIPv6</kw>
        </keywords>
        <abstract><p>This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support.  The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netlmm-pmip6-ipv4-support-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <doi>10.17487/RFC5844</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5845</doc-id>
        <title>Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6</title>
        <author>
            <name>A. Muhanna</name>
        </author>
        <author>
            <name>M. Khalil</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>PMIP6</kw>
            <kw>PMIPv6</kw>
            <kw>Downlink GRE Key</kw>
            <kw>Uplink GRE Key</kw>
            <kw>TLV-Header Tunneling</kw>
            <kw>TLV-Header Tunneling</kw>
            <kw>GRE Key Exchange</kw>
        </keywords>
        <abstract><p>This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session.  In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netlmm-grekey-option-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <doi>10.17487/RFC5845</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5846</doc-id>
        <title>Binding Revocation for IPv6 Mobility</title>
        <author>
            <name>A. Muhanna</name>
        </author>
        <author>
            <name>M. Khalil</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>P. Yegani</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>PMIP6</kw>
            <kw>PMIPv6</kw>
            <kw>Binding Revocation Indication</kw>
            <kw>BRI</kw>
            <kw>Binding Revocation Acknowledgement</kw>
            <kw>BRA</kw>
            <kw>MIP6</kw>
            <kw>DSMIP6</kw>
            <kw>Multiple Care-of Addresses</kw>
            <kw>PMIPv6 Revocation</kw>
            <kw>Bulk PMIPv6 Revocation</kw>
        </keywords>
        <abstract><p>This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources.  This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6.  The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mext-binding-revocation-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC5846</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5847</doc-id>
        <title>Heartbeat Mechanism for Proxy Mobile IPv6</title>
        <author>
            <name>V. Devarapalli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Koodli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Lim</name>
        </author>
        <author>
            <name>N. Kant</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>J. Laganier</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Node Reachability</kw>
            <kw>Restarts</kw>
            <kw>Failure Detection</kw>
        </keywords>
        <abstract><p>Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol.  The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain.  This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-netlmm-pmipv6-heartbeat-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5847</errata-url>
        <doi>10.17487/RFC5847</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5848</doc-id>
        <title>Signed Syslog Messages</title>
        <author>
            <name>J. Kelsey</name>
        </author>
        <author>
            <name>J. Callas</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>syslog</kw>
            <kw>syslog-sign</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages.  This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-syslog-sign-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <doi>10.17487/RFC5848</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5849</doc-id>
        <title>The OAuth 1.0 Protocol</title>
        <author>
            <name>E. Hammer-Lahav</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>authorization</kw>
            <kw>delegation</kw>
        </keywords>
        <abstract><p>OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user).  It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-hammer-oauth-10</draft>
        <obsoleted-by>
            <doc-id>RFC6749</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5849</errata-url>
        <doi>10.17487/RFC5849</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5850</doc-id>
        <title>A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>D. Petrie</name>
        </author>
        <author>
            <name>A. Johnston</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>call control</kw>
            <kw>multiparty</kw>
            <kw>features</kw>
            <kw>mixing</kw>
            <kw>refer</kw>
            <kw>3pcc</kw>
            <kw>Refer method</kw>
            <kw>Replaces header field</kw>
            <kw>Join header field</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract><p>This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP).  To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these.  The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships.  In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history.  This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipping-cc-framework-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5850</errata-url>
        <doi>10.17487/RFC5850</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5851</doc-id>
        <title>Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks</title>
        <author>
            <name>S. Ooghe</name>
        </author>
        <author>
            <name>N. Voigt</name>
        </author>
        <author>
            <name>M. Platnic</name>
        </author>
        <author>
            <name>T. Haag</name>
        </author>
        <author>
            <name>S. Wadhwa</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>Access Node Control Protocol</kw>
            <kw>Topology Discovery</kw>
            <kw>Loop Configuration</kw>
            <kw>Remote Connectivity Test</kw>
            <kw>Multicast</kw>
            <kw>Access Node</kw>
            <kw>Network Access Server</kw>
        </keywords>
        <abstract><p>The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.</p><p> This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ancp-framework-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ancp</wg_acronym>
        <doi>10.17487/RFC5851</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5852</doc-id>
        <title>RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network</title>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>D. Bramanti</name>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>S. Bardalai</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>resource reservation protocol</kw>
            <kw>handover procedures</kw>
        </keywords>
        <abstract><p>In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.</p><p> This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-pc-spc-rsvpte-ext-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC5852</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5853</doc-id>
        <title>Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments</title>
        <author>
            <name>J. Hautakorpi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>R. Penfield</name>
        </author>
        <author>
            <name>A. Hawrylyshen</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs).  The goal of this document is to describe the commonly provided functions of SBCs.  A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles.  This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipping-sbc-funcs-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5853</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5854</doc-id>
        <title>The Metalink Download Description Format</title>
        <author>
            <name>A. Bryan</name>
        </author>
        <author>
            <name>T. Tsujikawa</name>
        </author>
        <author>
            <name>N. McNab</name>
        </author>
        <author>
            <name>P. Poeml</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>file transfer</kw>
            <kw>mirrors</kw>
            <kw>data integrity</kw>
            <kw>hash</kw>
            <kw>xml</kw>
            <kw>http</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>ftp</kw>
            <kw>file transfer protocol</kw>
            <kw>metadata</kw>
            <kw>torrent</kw>
        </keywords>
        <abstract><p>This document specifies Metalink, an XML-based download description format.  Metalink describes download locations (mirrors), cryptographic hashes, and other information.  Clients can transparently use this information to reliably transfer files. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-bryan-metalink-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5854</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5855</doc-id>
        <title>Nameservers for IPv4 and IPv6 Reverse Zones</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>T. Manderson</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw> IN-ADDR.ARPA</kw>
            <kw>IP6.ARPA</kw>
            <kw>reverse mapping</kw>
        </keywords>
        <abstract><p>This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS.  These zones contain data that facilitate reverse mapping (address to name).  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-jabley-reverse-servers-01</draft>
        <is-also>
            <doc-id>BCP0155</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5855</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5856</doc-id>
        <title>Integration of Robust Header Compression over IPsec Security Associations</title>
        <author>
            <name>E. Ertekin</name>
        </author>
        <author>
            <name>R. Jasani</name>
        </author>
        <author>
            <name>C. Christou</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>ROHCoIPsec</kw>
        </keywords>
        <abstract><p>IP Security (IPsec) provides various security services for IP traffic.  However, the benefits of IPsec come at the cost of increased overhead.  This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).  By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-rohc-hcoipsec-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <doi>10.17487/RFC5856</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5857</doc-id>
        <title>IKEv2 Extensions to Support Robust Header Compression over IPsec</title>
        <author>
            <name>E. Ertekin</name>
        </author>
        <author>
            <name>C. Christou</name>
        </author>
        <author>
            <name>R. Jasani</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>ROHCoIPsec</kw>
        </keywords>
        <abstract><p>In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints.  Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters.  This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-ikev2-extensions-hcoipsec-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5857</errata-url>
        <doi>10.17487/RFC5857</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5858</doc-id>
        <title>IPsec Extensions to Support Robust Header Compression over IPsec</title>
        <author>
            <name>E. Ertekin</name>
        </author>
        <author>
            <name>C. Christou</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ROHC</kw>
            <kw>ROHCoIPsec</kw>
        </keywords>
        <abstract><p>Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization.  However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required.  This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rohc-ipsec-extensions-hcoipsec-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rohc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5858</errata-url>
        <doi>10.17487/RFC5858</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5859</doc-id>
        <title>TFTP Server Address Option for DHCPv4</title>
        <author>
            <name>R. Johnson</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>voip</kw>
        </keywords>
        <abstract><p>This memo documents existing usage for the "TFTP Server Address" option.  The option number currently in use is 150.  This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options.  The option is defined for DHCPv4 and works only with IPv4 addresses.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-raj-dhc-tftp-addr-option-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5859</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5860</doc-id>
        <title>Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks</title>
        <author>
            <name>M. Vigoureux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Ward</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Betts</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MPLS-TP</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile.  These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-oam-requirements-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5860</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5861</doc-id>
        <title>HTTP Cache-Control Extensions for Stale Content</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-nottingham-http-stale-controls-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5861</errata-url>
        <doi>10.17487/RFC5861</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5862</doc-id>
        <title>Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE</title>
        <author>
            <name>S. Yasukawa</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>gmpls</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</p><p> Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.</p><p> Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pce-p2mp-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC5862</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5863</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>E. Siegel</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>Email</kw>
            <kw>Electronic Mail</kw>
            <kw>Internet Mail</kw>
            <kw>Message Verification</kw>
        </keywords>
        <abstract><p>DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient.  The organization can be the author's, the originating sending site, an intermediary, or one of their agents.  A message can contain multiple signatures, from the same or different organizations involved with the message.  DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology.  This permits verification of a responsible organization, as well as the integrity of the message content.  DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.  DKIM's authentication of email identity can assist in the global control of "spam" and "phishing".  This document provides implementation, deployment, operational, and migration considerations for DKIM.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-dkim-deployment-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <doi>10.17487/RFC5863</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5864</doc-id>
        <title>DNS SRV Resource Records for AFS</title>
        <author>
            <name>R. Allbery</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>domain name system</kw>
            <kw>srv rr</kw>
            <kw>distributed file system</kw>
            <kw>afsdb rr</kw>
        </keywords>
        <abstract><p>This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS.  It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. [STANDARDS TRACK]</p></abstract>
        <draft>draft-allbery-afs-srv-records-05</draft>
        <updates>
            <doc-id>RFC1183</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5864</errata-url>
        <doi>10.17487/RFC5864</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5865</doc-id>
        <title>A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>M. Dolly</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>real-time traffic</kw>
        </keywords>
        <abstract><p>This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic.  This traffic class conforms to the Expedited Forwarding Per-Hop Behavior.  This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission.  This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-admitted-realtime-dscp-07</draft>
        <updates>
            <doc-id>RFC4542</doc-id>
            <doc-id>RFC4594</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5865</errata-url>
        <doi>10.17487/RFC5865</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5866</doc-id>
        <title>Diameter Quality-of-Service Application</title>
        <author>
            <name>D. Sun</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. McCann</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>AAA</kw>
            <kw>QoS</kw>
            <kw>Policy</kw>
            <kw>VoIP</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application.  The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network.  In particular, two modes of operation, namely "Pull" and "Push", are defined. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-dime-diameter-qos-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC5866</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5867</doc-id>
        <title>Building Automation Routing Requirements in Low-Power and Lossy Networks</title>
        <author>
            <name>J. Martocci</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. De Mil</name>
        </author>
        <author>
            <name>N. Riou</name>
        </author>
        <author>
            <name>W. Vermeylen</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks.  Pursuant to this effort, this document defines the IPv6 routing requirements for building automation.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-roll-building-routing-reqs-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC5867</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5868</doc-id>
        <title>Problem Statement on the Cross-Realm Operation of Kerberos</title>
        <author>
            <name>S. Sakane</name>
        </author>
        <author>
            <name>K. Kamada</name>
        </author>
        <author>
            <name>S. Zrelli</name>
        </author>
        <author>
            <name>M. Ishiyama</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.</p><p> This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-krb-wg-cross-problem-statement-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC5868</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5869</doc-id>
        <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
        <author>
            <name>H. Krawczyk</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-krawczyk-hkdf-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5869</errata-url>
        <doi>10.17487/RFC5869</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5870</doc-id>
        <title>A Uniform Resource Identifier for Geographic Locations ('geo' URI)</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <author>
            <name>C. Spanring</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>geography</kw>
            <kw>geo</kw>
            <kw>uri</kw>
            <kw>scheme</kw>
        </keywords>
        <abstract><p>This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name.  A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way.  The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-geo-uri-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5870</errata-url>
        <doi>10.17487/RFC5870</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5871</doc-id>
        <title>IANA Allocation Guidelines for the IPv6 Routing Header</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>routing type field</kw>
        </keywords>
        <abstract><p>This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-6man-iana-routing-header-00</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC5871</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5872</doc-id>
        <title>IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-arkko-pana-iana-02</draft>
        <updates>
            <doc-id>RFC5191</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5872</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5873</doc-id>
        <title>Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)</title>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pana-preauth-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5873</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5874</doc-id>
        <title>An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>J. Urpalainen</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Instant Messaging</kw>
        </keywords>
        <abstract><p>This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP).  This format reports which document has changed and its former and new entity tags.  It can report the differences between versions of the document, using an XML patch format.  It can report existing element and attribute content when versions of an XCAP server document change.  XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-xcap-diff-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC5874</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5875</doc-id>
        <title>An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package</title>
        <author>
            <name>J. Urpalainen</name>
        </author>
        <author>
            <name>D. Willis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>xcap-diff</kw>
            <kw>xcap diff</kw>
        </keywords>
        <abstract><p>This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources.  The initial synchronization information exchange and document updates are based on the XCAP Diff format. [STANDARDS TRACK]</p></abstract>
        <draft>draft-ietf-sip-xcapevent-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5875</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5876</doc-id>
        <title>Updates to Asserted Identity in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Elwell</name>
        </author>
        <date>
            <month>April</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>P-Asserted-Identity</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields.  These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method.  However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields.  This document extends RFC 3325 to cover these situations.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipping-update-pai-09</draft>
        <updates>
            <doc-id>RFC3325</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5876</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5877</doc-id>
        <title>The application/pkix-attr-cert Media Type for Attribute Certificates</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pkix-attr-cert-mime-type-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5877</errata-url>
        <doi>10.17487/RFC5877</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5878</doc-id>
        <title>Transport Layer Security (TLS) Authorization Extensions</title>
        <author>
            <name>M. Brown</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>handshake protocol</kw>
        </keywords>
        <abstract><p>This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol.  Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types.  Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-housley-tls-authz-extns-09</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8447</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5878</errata-url>
        <doi>10.17487/RFC5878</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5879</doc-id>
        <title>Heuristics for Detecting ESP-NULL Packets</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>D. McDonald</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>Wrapped ESP (WESP)</kw>
            <kw>deep-inspection</kw>
            <kw>packet inspection</kw>
        </keywords>
        <abstract><p>This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets.  These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected.  Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ipsecme-esp-null-heuristics-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC5879</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5880</doc-id>
        <title>Bidirectional Forwarding Detection (BFD)</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency.  It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bfd-base-11</draft>
        <updated-by>
            <doc-id>RFC7419</doc-id>
            <doc-id>RFC7880</doc-id>
            <doc-id>RFC8562</doc-id>
            <doc-id>RFC9747</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5880</errata-url>
        <doi>10.17487/RFC5880</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5881</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bfd-v4v6-1hop-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5881</errata-url>
        <doi>10.17487/RFC5881</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5882</doc-id>
        <title>Generic Application of Bidirectional Forwarding Detection (BFD)</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bfd-generic-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5882</errata-url>
        <doi>10.17487/RFC5882</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5883</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for Multihop Paths</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bfd-multihop-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC5883</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5884</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Multiprotocol Label Switching</kw>
            <kw>lsp ping</kw>
        </keywords>
        <abstract><p>One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure.  LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane.  BFD can be used for the former, but not for the latter.  However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages.  A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs.  This document describes the applicability of BFD in relation to LSP Ping for this application.  It also describes procedures for using BFD in this environment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-bfd-mpls-07</draft>
        <updates>
            <doc-id>RFC1122</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7726</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5884</errata-url>
        <doi>10.17487/RFC5884</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5885</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Pseudowire</kw>
            <kw>VCCV</kw>
            <kw>BFD</kw>
            <kw>VCCV-BFD</kw>
            <kw>PW OAM</kw>
        </keywords>
        <abstract><p>This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV).  VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-vccv-bfd-07</draft>
        <updated-by>
            <doc-id>RFC6478</doc-id>
            <doc-id>RFC7885</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC5885</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5886</doc-id>
        <title>A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <author>
            <name>Y. Ikejiri</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".</p><p> In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-monitoring-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC5886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5887</doc-id>
        <title>Renumbering Still Needs Work</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <author>
            <name>H. Flinck</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms.  It also summarises current technical proposals for additional mechanisms.  Finally, there is a gap analysis identifying possible areas for future work.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-carpenter-renum-needs-work-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5887</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5888</doc-id>
        <title>The Session Description Protocol (SDP) Grouping Framework</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>grouping</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes.  This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification.  Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses.  This document obsoletes RFC 3388. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-rfc3388bis-04</draft>
        <obsoletes>
            <doc-id>RFC3388</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8843</doc-id>
            <doc-id>RFC9143</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5888</errata-url>
        <doi>10.17487/RFC5888</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5889</doc-id>
        <title>IP Addressing Model in Ad Hoc Networks</title>
        <author>
            <name>E. Baccelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Townsley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mobile network</kw>
            <kw>ad hoc network</kw>
            <kw>MANET</kw>
            <kw>network architecture</kw>
            <kw>addressing framework</kw>
            <kw>configuration</kw>
            <kw>routing</kw>
            <kw>IP networks</kw>
        </keywords>
        <abstract><p>This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-autoconf-adhoc-addr-model-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>autoconf</wg_acronym>
        <doi>10.17487/RFC5889</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5890</doc-id>
        <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IDNA2008</kw>
            <kw>idn</kw>
            <kw>ascii</kw>
            <kw>characters</kw>
        </keywords>
        <abstract><p>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idnabis-defs-13</draft>
        <obsoletes>
            <doc-id>RFC3490</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4343</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>idnabis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5890</errata-url>
        <doi>10.17487/RFC5890</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5891</doc-id>
        <title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IDNA2008</kw>
            <kw>idn</kw>
            <kw>ascii</kw>
            <kw>characters</kw>
            <kw>idna applications</kw>
        </keywords>
        <abstract><p>This document is the revised protocol definition for Internationalized Domain Names (IDNs).  The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents.  This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself.  IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idnabis-protocol-18</draft>
        <obsoletes>
            <doc-id>RFC3490</doc-id>
            <doc-id>RFC3491</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3492</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>idnabis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5891</errata-url>
        <doi>10.17487/RFC5891</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5892</doc-id>
        <title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
        <author>
            <name>P. Faltstrom</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>IDNA</kw>
            <kw>DNS</kw>
            <kw>IDN</kw>
            <kw>Unicode</kw>
            <kw>IDNA2008</kw>
        </keywords>
        <abstract><p>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</p><p> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idnabis-tables-09</draft>
        <updated-by>
            <doc-id>RFC8753</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>idnabis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5892</errata-url>
        <doi>10.17487/RFC5892</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5893</doc-id>
        <title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
        <author>
            <name>H. Alvestrand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Karp</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IDNA2008</kw>
            <kw>idn</kw>
            <kw>ascii</kw>
            <kw>characters</kw>
            <kw>Bidi</kw>
        </keywords>
        <abstract><p>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges.  This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idnabis-bidi-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>idnabis</wg_acronym>
        <doi>10.17487/RFC5893</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5894</doc-id>
        <title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>IDNA2008</kw>
            <kw>idn</kw>
            <kw>ascii</kw>
            <kw>characters</kw>
        </keywords>
        <abstract><p>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed.  During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode.  Some of these issues require tuning of the existing protocols and the tables on which they depend.  This document provides an overview of a revised system and provides explanatory material for its components.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-idnabis-rationale-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>idnabis</wg_acronym>
        <doi>10.17487/RFC5894</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5895</doc-id>
        <title>Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>user input</kw>
            <kw>character mapping</kw>
            <kw>locale</kw>
            <kw>user interface</kw>
            <kw>Unicode</kw>
        </keywords>
        <abstract><p>In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS).  The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input.  This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-resman-idna2008-mappings-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5895</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5896</doc-id>
        <title>Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy</title>
        <author>
            <name>L. Hornquist Astrand</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>Several Generic Security Service Application Program Interface (GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers.  In effect, the server acts as an agent on behalf of the user.  Examples include web applications that need to access e-mail or file servers, including CIFS (Common Internet File System) file servers.  However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint.  Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation.  This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-lha-gssapi-delegate-policy-05</draft>
        <updates>
            <doc-id>RFC2743</doc-id>
            <doc-id>RFC2744</doc-id>
            <doc-id>RFC4120</doc-id>
            <doc-id>RFC4121</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5896</errata-url>
        <doi>10.17487/RFC5896</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5897</doc-id>
        <title>Identification of Communications Services in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>service identification</kw>
        </keywords>
        <abstract><p>This document considers the problem of service identification in the Session Initiation Protocol (SIP).  Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA).  This document discusses the uses of service identification, and outlines several architectural principles behind the process.  It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation.  It then outlines a set of recommended practices for service identification.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipping-service-identification-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC5897</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5898</doc-id>
        <title>Connectivity Preconditions for Session Description Protocol (SDP) Media Streams</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>preconditions</kw>
            <kw>connection</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract><p>This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework.  A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified.  The method of verification may vary depending on the type of transport used for the media.  For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets.  For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-connectivity-precon-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC5898</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5899</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5900</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC5901</doc-id>
        <title>Extensions to the IODEF-Document Class for Reporting Phishing</title>
        <author>
            <name>P. Cain</name>
        </author>
        <author>
            <name>D. Jevans</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>Incident Object Description Exchange Format</kw>
        </keywords>
        <abstract><p>This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud.  These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site.  Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-cain-post-inch-phishingextns-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5901</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5902</doc-id>
        <title>IAB Thoughts on IPv6 Network Address Translation</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <author>
            <name>G. Lebovitz</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>IPv6</kw>
            <kw>Transparency</kw>
            <kw>End-to-End</kw>
            <kw>Privacy</kw>
            <kw>Multihoming</kw>
        </keywords>
        <abstract><p>There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs).  This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-ipv6-nat-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC5902</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5903</doc-id>
        <title>Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2</title>
        <author>
            <name>D. Fu</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Elliptic Curve Cryptography</kw>
            <kw>ECC</kw>
            <kw>Internet Key Exchange</kw>
            <kw>elliptic curve</kw>
            <kw>Diffie-Hellman</kw>
            <kw>suite b</kw>
            <kw>nist curve</kw>
        </keywords>
        <abstract><p>This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.  These groups are based on modular arithmetic rather than binary arithmetic.  These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards.  In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups.  This document obsoletes RFC 4753.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-solinas-rfc4753bis-01</draft>
        <obsoletes>
            <doc-id>RFC4753</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5903</errata-url>
        <doi>10.17487/RFC5903</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5904</doc-id>
        <title>RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>AAA</kw>
            <kw>IEEE</kw>
            <kw>802.16</kw>
        </keywords>
        <abstract><p>This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-zorn-radius-pkmv1-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5904</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5905</doc-id>
        <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
        <author>
            <name>D. Mills</name>
        </author>
        <author>
            <name>J. Martin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Burbank</name>
        </author>
        <author>
            <name>W. Kasch</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>110</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>SNTP</kw>
            <kw>Synchronization</kw>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet.  This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol.  NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family.  NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs.  It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required.  It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.</p></abstract>
        <draft>draft-ietf-ntp-ntpv4-proto-13</draft>
        <obsoletes>
            <doc-id>RFC1305</doc-id>
            <doc-id>RFC4330</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7822</doc-id>
            <doc-id>RFC8573</doc-id>
            <doc-id>RFC9109</doc-id>
            <doc-id>RFC9748</doc-id>
            <doc-id>RFC9769</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5905</errata-url>
        <doi>10.17487/RFC5905</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5906</doc-id>
        <title>Network Time Protocol Version 4: Autokey Specification</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>ntp</kw>
            <kw>ntpv4</kw>
            <kw>public key cryptography</kw>
        </keywords>
        <abstract><p>This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.</p><p> This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ntp-autokey-08</draft>
        <updated-by>
            <doc-id>RFC9748</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5906</errata-url>
        <doi>10.17487/RFC5906</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5907</doc-id>
        <title>Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)</title>
        <author>
            <name>H. Gerstung</name>
        </author>
        <author>
            <name>C. Elliott</name>
        </author>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment.  As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent.  This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ntp-ntpv4-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5907</errata-url>
        <doi>10.17487/RFC5907</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5908</doc-id>
        <title>Network Time Protocol (NTP) Server Option for DHCPv6</title>
        <author>
            <name>R. Gayraud</name>
        </author>
        <author>
            <name>B. Lourdelet</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Dynamic Host Configuration Protocol for IPv6</kw>
        </keywords>
        <abstract><p>The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ntp-dhcpv6-ntp-opt-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5908</errata-url>
        <doi>10.17487/RFC5908</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5909</doc-id>
        <title>Securing Neighbor Discovery Proxy: Problem Statement</title>
        <author>
            <name>J-M. Combes</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>G. Daley</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>send</kw>
            <kw>secure neighbor discovery</kw>
        </keywords>
        <abstract><p>Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.</p><p> Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.</p><p> Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-csi-sndp-prob-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>csi</wg_acronym>
        <doi>10.17487/RFC5909</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5910</doc-id>
        <title>Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>epp</kw>
            <kw>Extensible Provisioning Protocol</kw>
            <kw>xml</kw>
            <kw>dns</kw>
            <kw>security</kw>
            <kw>dnssec</kw>
            <kw>delegation signer</kw>
            <kw>ds</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.  This document obsoletes RFC 4310. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gould-rfc4310bis-07</draft>
        <obsoletes>
            <doc-id>RFC4310</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5910</errata-url>
        <doi>10.17487/RFC5910</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5911</doc-id>
        <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>S/MIME</kw>
            <kw>PKIX</kw>
            <kw>ASN.1 modules</kw>
        </keywords>
        <abstract><p>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.  There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-smime-new-asn1-07</draft>
        <updated-by>
            <doc-id>RFC6268</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5911</errata-url>
        <doi>10.17487/RFC5911</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5912</doc-id>
        <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>117</page-count>
        <keywords>
            <kw>S/MIME</kw>
            <kw>PKIX</kw>
            <kw>ASN.1 modules</kw>
        </keywords>
        <abstract><p>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.  There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pkix-new-asn1-08</draft>
        <updated-by>
            <doc-id>RFC6960</doc-id>
            <doc-id>RFC9480</doc-id>
            <doc-id>RFC9810</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5912</errata-url>
        <doi>10.17487/RFC5912</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5913</doc-id>
        <title>Clearance Attribute and Authority Clearance Constraints Certificate Extension</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>S. Chokhani</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>x.509 certificate</kw>
        </keywords>
        <abstract><p>This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates.  The Clearance attribute is used to indicate the clearance held by the subject.  The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate.  The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-authorityclearanceconstraints-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5913</errata-url>
        <doi>10.17487/RFC5913</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5914</doc-id>
        <title>Trust Anchor Format</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Ashmore</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>trust anchor management</kw>
        </keywords>
        <abstract><p>This document describes a structure for representing trust anchor information.  A trust anchor is an authoritative entity represented by a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative.  The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-ta-format-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5914</errata-url>
        <doi>10.17487/RFC5914</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5915</doc-id>
        <title>Elliptic Curve Private Key Structure</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ec</kw>
            <kw>Standards for Efficient Cryptography Group</kw>
            <kw>SECG</kw>
        </keywords>
        <abstract><p>This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information.  The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-ecprivatekey-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5915</errata-url>
        <doi>10.17487/RFC5915</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5916</doc-id>
        <title>Device Owner Attribute</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document defines the Device Owner attribute.  It indicates the entity (e.g., company, organization, department, agency) that owns the device.  This attribute may be included in public key certificates and attribute certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-deviceowner-attribute-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5916</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5917</doc-id>
        <title>Clearance Sponsor Attribute</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document defines the clearance sponsor attribute.  It indicates the entity that sponsored (i.e., granted) the clearance.  This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-clearancesponsor-attribute-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5917</errata-url>
        <doi>10.17487/RFC5917</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5918</doc-id>
        <title>Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)</title>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>B. Thomas</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Wildcard</kw>
            <kw>Typed Wildcard FEC Element</kw>
            <kw>Typed Wildcard FEC Capability</kw>
        </keywords>
        <abstract><p>The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations.  This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures.  In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-typed-wildcard-07</draft>
        <updated-by>
            <doc-id>RFC7358</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5918</errata-url>
        <doi>10.17487/RFC5918</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5919</doc-id>
        <title>Signaling LDP Label Advertisement Completion</title>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>B. Thomas</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>label distribution protocol</kw>
            <kw>End-of-LIB</kw>
            <kw>Unrecognized Notification</kw>
        </keywords>
        <abstract><p>There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels.  The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer.  This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-end-of-lib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5919</errata-url>
        <doi>10.17487/RFC5919</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5920</doc-id>
        <title>Security Framework for MPLS and GMPLS Networks</title>
        <author>
            <name>L. Fang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <abstract><p>This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks.  This document addresses the security aspects that are relevant in the context of MPLS and GMPLS.  It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting.  This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-mpls-and-gmpls-security-framework-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5920</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5921</doc-id>
        <title>A Framework for MPLS in Transport Networks</title>
        <author>
            <name>M. Bocci</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Frost</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Levrau</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpls-tp</kw>
            <kw>transport profile</kw>
            <kw>oam</kw>
            <kw>itu-t</kw>
        </keywords>
        <abstract><p>This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.</p><p> This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-framework-12</draft>
        <updated-by>
            <doc-id>RFC6215</doc-id>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5921</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5922</doc-id>
        <title>Domain Certificates in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>S. Lawrence</name>
        </author>
        <author>
            <name>A. Jeffrey</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>Authentication</kw>
            <kw>Mutual Authentication</kw>
            <kw>X.509</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection.  More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication.  As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-domain-certs-07</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5922</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5923</doc-id>
        <title>Connection Reuse in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>V. Gurbani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>B. Tate</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TCP Connection</kw>
            <kw>SCTP Connection</kw>
            <kw>TLS Connection</kw>
            <kw>Transport Connection</kw>
            <kw>TLS</kw>
            <kw>Virtual Server</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract><p>This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction.  Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS).  For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP).  This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-connect-reuse-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5923</errata-url>
        <doi>10.17487/RFC5923</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5924</doc-id>
        <title>Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates</title>
        <author>
            <name>S. Lawrence</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>SIP Domain</kw>
            <kw>X.509 Certificate</kw>
        </keywords>
        <abstract><p>This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service.  As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-sip-eku-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC5924</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5925</doc-id>
        <title>The TCP Authentication Option</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>transmission control message</kw>
            <kw>digest</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract><p>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5).  TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5.  TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints.  The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes.  TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously.  TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-tcp-auth-opt-11</draft>
        <obsoletes>
            <doc-id>RFC2385</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5925</errata-url>
        <doi>10.17487/RFC5925</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5926</doc-id>
        <title>Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)</title>
        <author>
            <name>G. Lebovitz</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract><p>The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points.  There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms.  This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-tcp-ao-crypto-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5926</errata-url>
        <doi>10.17487/RFC5926</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5927</doc-id>
        <title>ICMP Attacks against TCP</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>vulnerability</kw>
            <kw>blind attacks</kw>
            <kw>connection-reset attack</kw>
            <kw>performance-degrading attack</kw>
            <kw>throughput-reduction attack</kw>
            <kw>source quench</kw>
            <kw>PMTUD</kw>
            <kw>Path-MTU Discovery</kw>
            <kw>ICMP Destination Unreachable</kw>
        </keywords>
        <abstract><p>This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP).  Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-tcpm-icmp-attacks-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5927</errata-url>
        <doi>10.17487/RFC5927</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5928</doc-id>
        <title>Traversal Using Relays around NAT (TURN) Resolution Mechanism</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>Traversal</kw>
        </keywords>
        <abstract><p>This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-turn-uri-10</draft>
        <updated-by>
            <doc-id>RFC7350</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC5928</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5929</doc-id>
        <title>Channel Bindings for TLS</title>
        <author>
            <name>J. Altman</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>channel</kw>
            <kw>binding</kw>
            <kw>channel-binding</kw>
            <kw>tls-unique</kw>
            <kw>tls-server-end-point</kw>
            <kw>tls-unique-for-telnet</kw>
        </keywords>
        <abstract><p>This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).</p><p> Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-altman-tls-channel-bindings-10</draft>
        <updated-by>
            <doc-id>RFC9266</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5929</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5930</doc-id>
        <title>Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol</title>
        <author>
            <name>S. Shen</name>
        </author>
        <author>
            <name>Y. Mao</name>
        </author>
        <author>
            <name>NSS. Murthy</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>initialization vector</kw>
            <kw>IKE_SA_INIT</kw>
        </keywords>
        <abstract><p>This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ipsecme-aes-ctr-ikev2-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC5930</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5931</doc-id>
        <title>Extensible Authentication Protocol (EAP) Authentication Using Only a Password</title>
        <author>
            <name>D. Harkins</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Password Authenticated Key Exchange</kw>
            <kw>Dictionary Attack</kw>
            <kw>Authentication EAP</kw>
        </keywords>
        <abstract><p>This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication.  The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker.  The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-harkins-emu-eap-pwd-14</draft>
        <updated-by>
            <doc-id>RFC8146</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5931</errata-url>
        <doi>10.17487/RFC5931</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5932</doc-id>
        <title>Camellia Cipher Suites for TLS</title>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>M. Kanda</name>
        </author>
        <author>
            <name>S. Kanno</name>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>block cipher</kw>
            <kw>security</kw>
            <kw>camellia</kw>
            <kw>tls</kw>
            <kw>cbc</kw>
            <kw>sha2</kw>
            <kw>camellia encryption algorithm</kw>
        </keywords>
        <abstract><p>This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.  It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family.  This document obsoletes RFC 4132. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kato-tls-rfc4132bis-05</draft>
        <obsoletes>
            <doc-id>RFC4132</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5932</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5933</doc-id>
        <title>Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Chuprina</name>
        </author>
        <author>
            <name>I. Ustinov</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>domain name system security extensions</kw>
            <kw>ECC</kw>
        </keywords>
        <abstract><p>This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-gost-07</draft>
        <updated-by>
            <doc-id>RFC6944</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5933</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5934</doc-id>
        <title>Trust Anchor Management Protocol (TAMP)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Ashmore</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>trust anchors</kw>
            <kw>TA</kw>
        </keywords>
        <abstract><p>This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store.  The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication.  The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-tamp-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5934</errata-url>
        <doi>10.17487/RFC5934</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5935</doc-id>
        <title>Expressing SNMP SMI Datatypes in XML Schema Definition Language</title>
        <author>
            <name>M. Ellison</name>
        </author>
        <author>
            <name>B. Natale</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>structure of management information</kw>
        </keywords>
        <abstract><p>This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language.  The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opsawg-smi-datatypes-in-xsd-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5935</errata-url>
        <doi>10.17487/RFC5935</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5936</doc-id>
        <title>DNS Zone Transfer Protocol (AXFR)</title>
        <author>
            <name>E. Lewis</name>
        </author>
        <author>
            <name>A. Hoenes</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>authoritative transfer</kw>
            <kw>AXFR mechanism</kw>
        </keywords>
        <abstract><p>The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.</p><p> The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-axfr-clarify-14</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9103</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5936</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5937</doc-id>
        <title>Using Trust Anchor Constraints during Certification Path Processing</title>
        <author>
            <name>S. Ashmore</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TA</kw>
        </keywords>
        <abstract><p>This document describes how to use information associated with a trust anchor public key when validating certification paths.  This information can be used to constrain the usage of a trust anchor.  Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-wallace-using-ta-constraints-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5937</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5938</doc-id>
        <title>Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>M. Chiba</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
        </keywords>
        <abstract><p>The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol.  This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers.  The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-twamp-session-cntrl-07</draft>
        <updates>
            <doc-id>RFC5357</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5938</errata-url>
        <doi>10.17487/RFC5938</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5939</doc-id>
        <title>Session Description Protocol (SDP) Capability Negotiation</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>multimedia session</kw>
            <kw>session announcement</kw>
            <kw>session invitation</kw>
        </keywords>
        <abstract><p>The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.</p><p> The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.</p><p> The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-sdp-capability-negotiation-13</draft>
        <updated-by>
            <doc-id>RFC6871</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5939</errata-url>
        <doi>10.17487/RFC5939</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5940</doc-id>
        <title>Additional Cryptographic Message Syntax (CMS) Revocation Information Choices</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>online certificate status protocol</kw>
            <kw>ocsp</kw>
            <kw>server-based certificate validation protocol</kw>
            <kw>scvp</kw>
        </keywords>
        <abstract><p>The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types.  The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats.  This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-additional-cms-ri-choices-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5940</errata-url>
        <doi>10.17487/RFC5940</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5941</doc-id>
        <title>Sharing Transaction Fraud Data</title>
        <author>
            <name>D. M'Raihi</name>
        </author>
        <author>
            <name>S. Boeyen</name>
        </author>
        <author>
            <name>M. Grandcolas</name>
        </author>
        <author>
            <name>S. Bajaj</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>thraud</kw>
            <kw>incident object description exchange format</kw>
            <kw>iodef</kw>
        </keywords>
        <abstract><p>This document describes a document format for exchanging transaction fraud (Thraud) information.  It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mraihi-inch-thraud-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5941</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5942</doc-id>
        <title>IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes</title>
        <author>
            <name>H. Singh</name>
        </author>
        <author>
            <name>W. Beebee</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>IPv6 specifies a model of a subnet that is different than the IPv4 subnet model.  The subtlety of the differences has resulted in incorrect implementations that do not interoperate.  This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix.  This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-ipv6-subnet-model-12</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5942</errata-url>
        <doi>10.17487/RFC5942</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5943</doc-id>
        <title>A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
        </keywords>
        <abstract><p>The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document.  In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-haberman-rpsl-reachable-test-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5943</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5944</doc-id>
        <title>IP Mobility Support for IPv4, Revised</title>
        <author>
            <name>C. Perkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet Protocol</kw>
            <kw>MIPv4</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-mip4-rfc3344bis-10</draft>
        <obsoletes>
            <doc-id>RFC3344</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5944</errata-url>
        <doi>10.17487/RFC5944</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5945</doc-id>
        <title>Resource Reservation Protocol (RSVP) Proxy Approaches</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>A. Guillou</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows.  RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling.  Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.  This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable.  This allows resource reservations to be established on a critical subset of the end-to-end path.  This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP.  This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach.  However, such extensions are outside the scope of this document.  Finally, practical use cases for RSVP proxy are described.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-proxy-approaches-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5945</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5946</doc-id>
        <title>Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>A. Narayanan</name>
        </author>
        <author>
            <name>A. Guillou</name>
        </author>
        <author>
            <name>H. Malik</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
        </keywords>
        <abstract><p>Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows.  With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling.  Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.  Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver.  This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy.  However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender.  This document specifies these extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-proxy-proto-11</draft>
        <updates>
            <doc-id>RFC2205</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC5946</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5947</doc-id>
        <title>Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Elwell</name>
        </author>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Trunking</kw>
            <kw>pbx</kw>
            <kw>private branch exchange</kw>
        </keywords>
        <abstract><p>This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs).  The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-martini-reqs-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>martini</wg_acronym>
        <doi>10.17487/RFC5947</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5948</doc-id>
        <title>Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16</title>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>packet cs</kw>
        </keywords>
        <abstract><p>IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer.</p><p> This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>16ng</wg_acronym>
        <doi>10.17487/RFC5948</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5949</doc-id>
        <title>Fast Handovers for Proxy Mobile IPv6</title>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>F. Xia</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>PFMIPv6</kw>
            <kw>handoff</kw>
            <kw>PMIPv6</kw>
            <kw>predictive</kw>
            <kw>reactive</kw>
        </keywords>
        <abstract><p>Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.</p><p> When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mipshop-pfmipv6-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC5949</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5950</doc-id>
        <title>Network Management Framework for MPLS-based Transport Networks</title>
        <author>
            <name>S. Mansfield</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Gray</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Lam</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>mpls-tp</kw>
            <kw>network management framework</kw>
        </keywords>
        <abstract><p>This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).</p><p> This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.</p><p> The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-nm-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC5950</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5951</doc-id>
        <title>Network Management Requirements for MPLS-based Transport Networks</title>
        <author>
            <name>K. Lam</name>
        </author>
        <author>
            <name>S. Mansfield</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MPLS Transport Profile</kw>
            <kw>mpls-tp</kw>
        </keywords>
        <abstract><p>This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP).  The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed.  That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP.  This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-nm-req-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5951</errata-url>
        <doi>10.17487/RFC5951</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5952</doc-id>
        <title>A Recommendation for IPv6 Address Text Representation</title>
        <author>
            <name>S. Kawamura</name>
        </author>
        <author>
            <name>M. Kawashima</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>text representation</kw>
            <kw>canonical</kw>
        </keywords>
        <abstract><p>As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text.  While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users.  This document defines a canonical textual representation format.  It does not define a format for internal storage, such as within an application or database.  It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-text-addr-representation-07</draft>
        <updates>
            <doc-id>RFC4291</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5952</errata-url>
        <doi>10.17487/RFC5952</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5953</doc-id>
        <title>Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>dtls</kw>
            <kw>datagram transport layer security</kw>
            <kw>tls transport model</kw>
            <kw>tlstm</kw>
            <kw>SNMP-TLS-TM-MIB</kw>
        </keywords>
        <abstract><p>This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.</p><p> This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.</p><p> This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-dtls-tm-14</draft>
        <obsoleted-by>
            <doc-id>RFC6353</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5953</errata-url>
        <doi>10.17487/RFC5953</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5954</doc-id>
        <title>Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261</title>
        <author>
            <name>V. Gurbani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Tate</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>session initiation protocol</kw>
            <kw>Augmented Backus-Naur Form</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>IPv6reference</kw>
            <kw>IPv6address</kw>
        </keywords>
        <abstract><p>This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261.  It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-ipv6-abnf-fix-05</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5954</errata-url>
        <doi>10.17487/RFC5954</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5955</doc-id>
        <title>The application/timestamped-data Media Type</title>
        <author>
            <name>A. Santoni</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>TimeStampedData envelopes</kw>
        </keywords>
        <abstract><p>This document defines a new media type for TimeStampedData envelopes as described in RFC 5544.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-santoni-media-type-tsd-00</draft>
        <updates>
            <doc-id>RFC5544</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5955</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5956</doc-id>
        <title>Forward Error Correction Grouping Semantics in the Session Description Protocol</title>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>loss repair</kw>
            <kw>grouping</kw>
            <kw>sdp</kw>
            <kw>media lines</kw>
        </keywords>
        <abstract><p>This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP).  The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888).  These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows.  SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-rfc4756bis-10</draft>
        <obsoletes>
            <doc-id>RFC4756</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC5956</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5957</doc-id>
        <title>Display-Based Address Sorting for the IMAP4 SORT Extension</title>
        <author>
            <name>D. Karp</name>
        </author>
        <date>
            <month>July</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Internet Message Access Protocol</kw>
        </keywords>
        <abstract><p>This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-morg-sortdisplay-03</draft>
        <updates>
            <doc-id>RFC5256</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>morg</wg_acronym>
        <doi>10.17487/RFC5957</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5958</doc-id>
        <title>Asymmetric Key Packages</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>private key</kw>
            <kw>private-key information</kw>
            <kw>rsa laboratories</kw>
            <kw>private-key syntax</kw>
            <kw>change control</kw>
        </keywords>
        <abstract><p>This document defines the syntax for private-key information and a content type for it.  Private-key information includes a private key for a specified public-key algorithm and a set of attributes.  The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type.  This document obsoletes RFC 5208. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-asymmetrickeyformat-05</draft>
        <obsoletes>
            <doc-id>RFC5208</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5958</errata-url>
        <doi>10.17487/RFC5958</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5959</doc-id>
        <title>Algorithms for Asymmetric Key Package Content Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>EncryptedPrivateKeyInfo</kw>
            <kw>AsymmetricKeyPackage</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958.  It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-asymmetrickeyformat-algs-01</draft>
        <updated-by>
            <doc-id>RFC6162</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5959</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5960</doc-id>
        <title>MPLS Transport Profile Data Plane Architecture</title>
        <author>
            <name>D. Frost</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Bocci</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>mpls-tp</kw>
            <kw>transport profile</kw>
            <kw>itu-t</kw>
            <kw>dataplane</kw>
            <kw>gal</kw>
            <kw>gach</kw>
        </keywords>
        <abstract><p>The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-data-plane-04</draft>
        <updated-by>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5960</errata-url>
        <doi>10.17487/RFC5960</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5961</doc-id>
        <title>Improving TCP's Robustness to Blind In-Window Attacks</title>
        <author>
            <name>A. Ramaiah</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Dalal</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RST</kw>
            <kw>SYN</kw>
            <kw>FIN</kw>
            <kw>attack</kw>
            <kw>Data Injection</kw>
            <kw>vulnerability</kw>
            <kw>blind attacks</kw>
            <kw>BGP</kw>
            <kw>spoof</kw>
            <kw>mitigation</kw>
        </keywords>
        <abstract><p>TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s).  A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-tcpsecure-13</draft>
        <updated-by>
            <doc-id>RFC9293</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5961</errata-url>
        <doi>10.17487/RFC5961</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5962</doc-id>
        <title>Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PIDF-LO,location,dynamic,speed,velocity,orientation</kw>
        </keywords>
        <abstract><p>The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity.  This document defines PIDF-LO extensions to convey information about moving objects.  Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. [STANDARDS TRACK]</p></abstract>
        <draft>draft-singh-geopriv-pidf-lo-dynamic-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5962</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5963</doc-id>
        <title>IPv6 Deployment in Internet Exchange Points (IXPs)</title>
        <author>
            <name>R. Gagliano</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IXP</kw>
            <kw>deployment</kw>
            <kw>exchange</kw>
        </keywords>
        <abstract><p>This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs).  It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed.  IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-v6inixp-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC5963</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5964</doc-id>
        <title>Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>hole</kw>
            <kw>polygon</kw>
            <kw>pidf-lo</kw>
            <kw>service boundary</kw>
            <kw>location</kw>
            <kw>LoST</kw>
        </keywords>
        <abstract><p>This document describes how holes can be specified in geodetic service boundaries.  One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ecrit-specifying-holes-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC5964</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5965</doc-id>
        <title>An Extensible Format for Email Feedback Reports</title>
        <author>
            <name>Y. Shafranovich</name>
        </author>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>feedback-report</kw>
        </keywords>
        <abstract><p>This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties.  This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-base-06</draft>
        <updated-by>
            <doc-id>RFC6650</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5965</errata-url>
        <doi>10.17487/RFC5965</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5966</doc-id>
        <title>DNS Transport over TCP - Implementation Requirements</title>
        <author>
            <name>R. Bellis</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>TCP/IP</kw>
        </keywords>
        <abstract><p>This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dns-tcp-requirements-03</draft>
        <obsoleted-by>
            <doc-id>RFC7766</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC1123</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC5966</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5967</doc-id>
        <title>The application/pkcs10 Media Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986.  It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-application-pkcs10-media-type-05</draft>
        <updates>
            <doc-id>RFC2986</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5967</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5968</doc-id>
        <title>Guidelines for Extending the RTP Control Protocol (RTCP)</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers.  This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses.  The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses.  This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-avt-rtcp-guidelines-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5968</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5969</doc-id>
        <title>IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification</title>
        <author>
            <name>W. Townsley</name>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>6rd</kw>
            <kw>Provider 6to4</kw>
            <kw> IPv6 softwire</kw>
            <kw>IPv6 Transition</kw>
            <kw>6to4</kw>
        </keywords>
        <abstract><p>This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure.  Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-ipv6-6rd-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5969</errata-url>
        <doi>10.17487/RFC5969</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5970</doc-id>
        <title>DHCPv6 Options for Network Boot</title>
        <author>
            <name>T. Huth</name>
        </author>
        <author>
            <name>J. Freimann</name>
        </author>
        <author>
            <name>V. Zimmer</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>boot</kw>
            <kw>IPv6</kw>
            <kw>DHCPv6</kw>
        </keywords>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network.  This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-opt-netboot-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC5970</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5971</doc-id>
        <title>GIST: General Internet Signalling Transport</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>R. Hancock</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>154</page-count>
        <keywords>
            <kw>nsis</kw>
            <kw>next steps in signaling</kw>
        </keywords>
        <abstract><p>This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network.  The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications.  GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path.  The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-ntlp-20</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5971</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5972</doc-id>
        <title>General Internet Signaling Transport (GIST) State Machine</title>
        <author>
            <name>T. Tsenov</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>X. Fu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Aoun</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This document describes state machines for the General Internet Signaling Transport (GIST).  The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented.</p></abstract>
        <draft>draft-ietf-nsis-ntlp-statemachine-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5972</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5973</doc-id>
        <title>NAT/Firewall NSIS Signaling Layer Protocol (NSLP)</title>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>C. Aoun</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>Next Steps in Signaling</kw>
            <kw>NSIS</kw>
            <kw>Path-coupled signaling</kw>
            <kw>Middlebox</kw>
        </keywords>
        <abstract><p>This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls.  This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows.  For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic.  The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group.  The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-nslp-natfw-25</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5973</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5974</doc-id>
        <title>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling</title>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>A. McDonald</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>102</page-count>
        <keywords>
            <kw>QoS</kw>
        </keywords>
        <abstract><p>This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet.  It is in accordance with the framework and requirements developed in NSIS.  Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it.  The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models.  It is simplified by the elimination of support for multicast flows.  This specification explains the overall protocol approach, describes the design decisions made, and provides examples.  It specifies object, message formats, and processing rules.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-qos-nslp-18</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5974</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5975</doc-id>
        <title>QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)</title>
        <author>
            <name>G. Ash</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Bader</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Kappler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Oran</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv.  Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC.  This document defines a template for the QSPEC including a number of QSPEC parameters.  The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP.  While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models.  The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-qspec-24</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5975</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5976</doc-id>
        <title>Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes</title>
        <author>
            <name>G. Ash</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>M. Dolly</name>
        </author>
        <author>
            <name>P. Tarapore</name>
        </author>
        <author>
            <name>C. Dvorak</name>
        </author>
        <author>
            <name>Y. El Mghazli</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>qos-nslp</kw>
            <kw>qos-nslp quality-of-service model</kw>
            <kw>qspec</kw>
        </keywords>
        <abstract><p>This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling.  Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-y1541-qosm-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5976</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5977</doc-id>
        <title>RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv</title>
        <author>
            <name>A. Bader</name>
        </author>
        <author>
            <name>L. Westberg</name>
        </author>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>C. Kappler</name>
        </author>
        <author>
            <name>T. Phelan</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>128</page-count>
        <keywords>
            <kw>next steps in signaling</kw>
            <kw>resource managment in diffserv</kw>
        </keywords>
        <abstract><p>This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept.  RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks.  The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network.  The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow.  Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination.  In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-rmd-20</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5977</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5978</doc-id>
        <title>Using and Extending the NSIS Protocol Family</title>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>R. Bless</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>E. Davies</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Signaling</kw>
            <kw>NTLP</kw>
            <kw>NSLP</kw>
            <kw>GIST</kw>
            <kw>QoS NSLP</kw>
            <kw>NAT/Firewall</kw>
            <kw>NSLP</kw>
            <kw>IP resources</kw>
            <kw>Extensibility</kw>
        </keywords>
        <abstract><p>This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010.  It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-nsis-ext-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5978</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5979</doc-id>
        <title>NSIS Operation over IP Tunnels</title>
        <author>
            <name>C. Shen</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S. Lee</name>
        </author>
        <author>
            <name>J. Bang</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>nsis qos</kw>
            <kw>next steps in signaling</kw>
        </keywords>
        <abstract><p>NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path.  When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments.  Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path.  The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields.  Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets.  This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-tunnel-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5979</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5980</doc-id>
        <title>NSIS Protocol Operation in Mobile Environments</title>
        <author>
            <name>T. Sanda</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Fu</name>
        </author>
        <author>
            <name>S. Jeong</name>
        </author>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management.  This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-nsis-applicability-mobility-signaling-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC5980</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5981</doc-id>
        <title>Authorization for NSIS Signaling Layer Protocols</title>
        <author>
            <name>J. Manner</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>R. Bless</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Next Steps in Signaling</kw>
            <kw>gist</kw>
            <kw>General Internet Signaling Transport</kw>
        </keywords>
        <abstract><p>Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization.  Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources.  This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols.  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 coordinate actions between the signaling and transport planes.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-nslp-auth-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5981</errata-url>
        <doi>10.17487/RFC5981</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5982</doc-id>
        <title>IP Flow Information Export (IPFIX) Mediation: Problem Statement</title>
        <author>
            <name>A. Kobayashi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Claise</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>flow-based measurement</kw>
        </keywords>
        <abstract><p>Flow-based measurement is a popular method for various network monitoring usages.  The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve.  This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ipfix-mediators-problem-statement-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC5982</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5983</doc-id>
        <title>Mailing Lists and Internationalized Email Addresses</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document describes considerations for mailing lists with the introduction of internationalized email addresses.</p><p> This document makes some specific recommendations on how mailing lists should act in various situations. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-eai-mailinglist-07</draft>
        <obsoleted-by>
            <doc-id>RFC6783</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC5983</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5984</doc-id>
        <title>Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding</title>
        <author>
            <name>K-M. Moller</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>extra sensory perception</kw>
        </keywords>
        <abstract><p>This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-moller-esp-based-forwarding-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc5984</errata-url>
        <doi>10.17487/RFC5984</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5985</doc-id>
        <title>HTTP-Enabled Location Delivery (HELD)</title>
        <author>
            <name>M. Barnes</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>layer 7 location configuration protocol</kw>
            <kw>l7 lcp</kw>
        </keywords>
        <abstract><p>This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP.  The L7 LCP is used for retrieving location information from a server within an access network.  It includes options for retrieving location information in two forms: by value and by reference.  The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-http-location-delivery-16</draft>
        <updated-by>
            <doc-id>RFC7840</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC5985</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5986</doc-id>
        <title>Discovering the Local Location Information Server (LIS)</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>u-naptr</kw>
            <kw>uri-enabled naptr</kw>
        </keywords>
        <abstract><p>Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network.  A method is described for the discovery of a LIS in the access network serving a Device.  Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name.  This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-lis-discovery-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5986</errata-url>
        <doi>10.17487/RFC5986</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5987</doc-id>
        <title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>header field parameter</kw>
            <kw>internationalization</kw>
        </keywords>
        <abstract><p>By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set.  RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers.  This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-reschke-rfc2231-in-http-12</draft>
        <obsoleted-by>
            <doc-id>RFC8187</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5987</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5988</doc-id>
        <title>Web Linking</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Link</kw>
            <kw>linking</kw>
            <kw>http header</kw>
            <kw>link relation</kw>
            <kw>web</kw>
        </keywords>
        <abstract><p>This document specifies relation types for Web links, and defines a registry for them.  It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-nottingham-http-link-header-10</draft>
        <obsoleted-by>
            <doc-id>RFC8288</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4287</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5988</errata-url>
        <doi>10.17487/RFC5988</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5989</doc-id>
        <title>A SIP Event Package for Subscribing to Changes to an HTTP Resource</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Link Relations</kw>
            <kw>Syndication</kw>
            <kw>Atom</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons.  In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted.  This document proposes a mechanism, based on the SIP Event Framework, for doing so. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-roach-sip-http-subscribe-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5989</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5990</doc-id>
        <title>Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>J. Randall</name>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <author>
            <name>J. Brainard</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>key encapsulation mechanism</kw>
            <kw>generic hybrid cipher</kw>
        </keywords>
        <abstract><p>The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS).  The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.</p></abstract>
        <draft>draft-ietf-smime-cms-rsa-kem-13</draft>
        <obsoleted-by>
            <doc-id>RFC9690</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>smime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5990</errata-url>
        <doi>10.17487/RFC5990</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5991</doc-id>
        <title>Teredo Security Updates</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>J. Hoagland</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>teredo ipv6 address</kw>
        </keywords>
        <abstract><p>The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address.  This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-krishnan-v6ops-teredo-update-10</draft>
        <updates>
            <doc-id>RFC4380</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5991</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5992</doc-id>
        <title>Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic</title>
        <author>
            <name>S. Sharikov</name>
        </author>
        <author>
            <name>D. Miloshevic</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Bosnian and Serbian</kw>
            <kw>Bulgarian</kw>
            <kw>Byelorussian</kw>
            <kw>Belarusian</kw>
            <kw>Belarusan</kw>
            <kw>Kildin Sami</kw>
            <kw>Macedonian</kw>
            <kw>Montenegrin</kw>
            <kw>Russian</kw>
            <kw>Ukrainian</kw>
        </keywords>
        <abstract><p>This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone.  It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-sharikov-idn-reg-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC5992</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5993</doc-id>
        <title>RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)</title>
        <author>
            <name>X. Duan</name>
        </author>
        <author>
            <name>S. Wang</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>K. Hellwig</name>
        </author>
        <author>
            <name>I. Johansson</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>speech codec</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP).  The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-gsm-hr-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC5993</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5994</doc-id>
        <title>Application of Ethernet Pseudowires to MPLS Transport Networks</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Morrow</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>R. Cherukuri</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>N. Harrison</name>
        </author>
        <author>
            <name>B. Niven-Jenkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>mpls-tp</kw>
        </keywords>
        <abstract><p>Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.</p><p> Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.</p><p> This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pwe3-mpls-transport-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5994</errata-url>
        <doi>10.17487/RFC5994</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5995</doc-id>
        <title>Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>POST</kw>
            <kw>WebDAV</kw>
            <kw>Collections</kw>
            <kw>Collection Members</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".</p><p> This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.</p><p> This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-reschke-webdav-post-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC5995</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5996</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>C. Kaufman</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>138</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IPsec</kw>
        </keywords>
        <abstract><p>This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2bis-11</draft>
        <obsoletes>
            <doc-id>RFC4306</doc-id>
            <doc-id>RFC4718</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7296</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC5998</doc-id>
            <doc-id>RFC6989</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5996</errata-url>
        <doi>10.17487/RFC5996</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5997</doc-id>
        <title>Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>August</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>status-server</kw>
        </keywords>
        <abstract><p>This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server.  This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-radext-status-server-09</draft>
        <updates>
            <doc-id>RFC2866</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc5997</errata-url>
        <doi>10.17487/RFC5997</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC5998</doc-id>
        <title>An Extension for EAP-Only Authentication in IKEv2</title>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>mutual authentication</kw>
            <kw>password</kw>
            <kw>credentials</kw>
            <kw>AAA</kw>
            <kw>key agreement</kw>
            <kw>channel binding</kw>
        </keywords>
        <abstract><p>IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.</p><p> This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-eap-mutual-05</draft>
        <updates>
            <doc-id>RFC5996</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC5998</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC5999</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6000</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6001</doc-id>
        <title>Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)</title>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <author>
            <name>M. Vigoureux</name>
        </author>
        <author>
            <name>K. Shiomoto</name>
        </author>
        <author>
            <name>D. Brungard</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
        </keywords>
        <abstract><p>There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).</p><p> This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-mln-extensions-12</draft>
        <updates>
            <doc-id>RFC4202</doc-id>
            <doc-id>RFC4203</doc-id>
            <doc-id>RFC4206</doc-id>
            <doc-id>RFC4874</doc-id>
            <doc-id>RFC4974</doc-id>
            <doc-id>RFC5307</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6001</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6002</doc-id>
        <title>Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Generalized Multi-Protocol Label Switching</kw>
        </keywords>
        <abstract><p>This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS).  The first extension defines the new switching type Data Channel Switching Capable.  Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces.  The second extension defines a new type of generalized label and updates related objects.  The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-dcsc-channel-ext-04</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
            <doc-id>RFC3473</doc-id>
            <doc-id>RFC3945</doc-id>
            <doc-id>RFC4202</doc-id>
            <doc-id>RFC4203</doc-id>
            <doc-id>RFC5307</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6002</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6003</doc-id>
        <title>Ethernet Traffic Parameters</title>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>mef</kw>
            <kw>Metro Ethernet Forum</kw>
            <kw>MEF10.1</kw>
        </keywords>
        <abstract><p>This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-ethernet-traffic-parameters-10</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6003</errata-url>
        <doi>10.17487/RFC6003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6004</doc-id>
        <title>Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Generalized Multi-Protocol Label Switching</kw>
            <kw>Metro Ethernet Forum</kw>
            <kw>MEF</kw>
        </keywords>
        <abstract><p>This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS).  This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011.  Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered.  Support for MEF- and ITU-defined parameters is also covered.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ether-svcs-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6004</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6005</doc-id>
        <title>Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>mef</kw>
            <kw>itu</kw>
            <kw>International Telecommunication Union</kw>
            <kw>i-nni</kw>
            <kw>internal nni</kw>
        </keywords>
        <abstract><p>This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI).  This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011.  This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching".  This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-mef-uni-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6006</doc-id>
        <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths</title>
        <author>
            <name>Q. Zhao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. King</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Verhaeghe</name>
        </author>
        <author>
            <name>T. Takeda</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>J. Meuric</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>END-POINTS</kw>
            <kw>fragmentation</kw>
        </keywords>
        <abstract><p>Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.</p><p> This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pce-pcep-p2mp-extensions-11</draft>
        <obsoleted-by>
            <doc-id>RFC8306</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6006</errata-url>
        <doi>10.17487/RFC6006</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6007</doc-id>
        <title>Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations</title>
        <author>
            <name>I. Nishioka</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.</p><p> This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pce-pcep-svec-list-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC6007</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6008</doc-id>
        <title>Authentication-Results Registration for Differentiating among Cryptographic Results</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>DomainKeys</kw>
            <kw>SenderID</kw>
            <kw>SPF</kw>
            <kw>Authentication</kw>
            <kw>Reputation</kw>
        </keywords>
        <abstract><p>This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kucherawy-authres-header-b-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6008</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6009</doc-id>
        <title>Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>ESMTP</kw>
            <kw>Sieve</kw>
        </keywords>
        <abstract><p>This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language.  The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively.  The "redirect-dsn" and "redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-freed-sieve-notary-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6009</errata-url>
        <doi>10.17487/RFC6009</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6010</doc-id>
        <title>Cryptographic Message Syntax (CMS) Content Constraints Extension</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Ashmore</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>authorization</kw>
            <kw>PKI</kw>
            <kw>certificate</kw>
            <kw>trust anchor</kw>
            <kw>TAMP,</kw>
        </keywords>
        <abstract><p>This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension.  This extension is used to determine whether a public key is appropriate to use in the processing of a protected content.  In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content.  The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate.  If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-housley-cms-content-constraints-extn-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6010</errata-url>
        <doi>10.17487/RFC6010</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6011</doc-id>
        <title>Session Initiation Protocol (SIP) User Agent Configuration</title>
        <author>
            <name>S. Lawrence</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Elwell</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>DHCP</kw>
            <kw>DHCPv6</kw>
        </keywords>
        <abstract><p>This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-lawrence-sipforum-user-agent-config-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6011</errata-url>
        <doi>10.17487/RFC6011</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6012</doc-id>
        <title>Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>T. Petch</name>
        </author>
        <author>
            <name>R. Gerhards</name>
        </author>
        <author>
            <name>H. Feng</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol.  It provides a secure transport for syslog messages in cases where a connectionless transport is desired.</p></abstract>
        <draft>draft-ietf-syslog-dtls-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9662</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>syslog</wg_acronym>
        <doi>10.17487/RFC6012</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6013</doc-id>
        <title>TCP Cookie Transactions (TCPCT)</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake.  The Initiator (client) has sole responsibility for ensuring required delays between connections.  The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-simpson-tcpct-03</draft>
        <obsoleted-by>
            <doc-id>RFC7805</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6013</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6014</doc-id>
        <title>Cryptographic Algorithm Identifier Allocation for DNSSEC</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>digital signatures</kw>
            <kw>algorithms</kw>
        </keywords>
        <abstract><p>This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated.  It changes the requirement from "standard required" to "RFC Required".  It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-alg-allocation-03</draft>
        <updates>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9157</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6014</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6015</doc-id>
        <title>RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)</title>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>interleaving</kw>
            <kw>loss repair</kw>
            <kw>loss protection</kw>
            <kw>DVB AL-FEC</kw>
        </keywords>
        <abstract><p>This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP.  The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols.  The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity.  The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fecframe-interleaved-fec-scheme-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6015</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6016</doc-id>
        <title>Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs</title>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>A. Narayanan</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>l3vpn</kw>
        </keywords>
        <abstract><p>RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6.  It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers.  This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links.  Optionally, admission control across the provider's backbone may also be supported. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-l3vpn-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6016</errata-url>
        <doi>10.17487/RFC6016</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6017</doc-id>
        <title>Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field</title>
        <author>
            <name>K. Meadors</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>EDIINT-Features</kw>
        </keywords>
        <abstract><p>With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality.  These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations.  The EDIINT-Features header field provides a means to resolve these problems and support new functionality.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-meadors-ediint-features-header-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6017</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6018</doc-id>
        <title>IPv4 and IPv6 Greynets</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>W. Harrop</name>
        </author>
        <author>
            <name>G. Armitage</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>darknets</kw>
        </keywords>
        <abstract><p>This note discusses a feature to support building Greynets for IPv4 and IPv6.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-baker-v6ops-greynet-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6018</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6019</doc-id>
        <title>BinaryTime: An Alternate Format for Representing Date and Time in ASN.1</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>signing-time attribute</kw>
            <kw>cryptographic message syntax</kw>
            <kw>cms</kw>
            <kw>SignedData</kw>
            <kw>AuthenticatedData</kw>
        </keywords>
        <abstract><p>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 5652. [STANDARDS-TRACK]</p></abstract>
        <draft>rfc4049bis</draft>
        <obsoletes>
            <doc-id>RFC4049</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6019</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6020</doc-id>
        <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
        <author>
            <name>M. Bjorklund</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>173</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>XML</kw>
            <kw>data modelling</kw>
        </keywords>
        <abstract><p>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netmod-yang-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6020</errata-url>
        <doi>10.17487/RFC6020</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6021</doc-id>
        <title>Common YANG Data Types</title>
        <author>
            <name>J. Schoenwaelder</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>NETCONF</kw>
        </keywords>
        <abstract><p>This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netmod-yang-types-09</draft>
        <obsoleted-by>
            <doc-id>RFC6991</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC6021</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6022</doc-id>
        <title>YANG Module for NETCONF Monitoring</title>
        <author>
            <name>M. Scott</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>NETCONF</kw>
            <kw>YANG</kw>
            <kw>monitoring</kw>
        </keywords>
        <abstract><p>This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol.  The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics.  This data facilitates the management of a NETCONF server.  This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF &lt;get-schema&gt; operation to retrieve them. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-monitoring-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6022</errata-url>
        <doi>10.17487/RFC6022</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6023</doc-id>
        <title>A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>R. Singh</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA.  This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.</p></abstract>
        <draft>draft-nir-ipsecme-childless-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6024</doc-id>
        <title>Trust Anchor Management Requirements</title>
        <author>
            <name>R. Reddy</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>PKI</kw>
            <kw>certificates</kw>
            <kw>digital signatures</kw>
        </keywords>
        <abstract><p>A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.  A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.  This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pkix-ta-mgmt-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC6024</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6025</doc-id>
        <title>ASN.1 Translation</title>
        <author>
            <name>C. Wallace</name>
        </author>
        <author>
            <name>C. Gardiner</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Basic Encoding Rules</kw>
            <kw>Distinguished Encoding Rules</kw>
            <kw>PKIX</kw>
            <kw>S/MIME</kw>
        </keywords>
        <abstract><p>Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years.  Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1.  Not all ASN.1 compilers support both older and current syntax.  This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire".  This document does not provide a comprehensive tutorial of any version of ASN.1.  Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pkix-asn1-translation-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC6025</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6026</doc-id>
        <title>Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>T. Zourzouvillys</name>
        </author>
        <date>
            <month>September</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>state machine</kw>
            <kw>retransmission</kw>
        </keywords>
        <abstract><p>This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests.  Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request.  The correction involves modifying the INVITE transaction state machines.  The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-invfix-01</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6026</errata-url>
        <doi>10.17487/RFC6026</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6027</doc-id>
        <title>IPsec Cluster Problem Statement</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IKEv2</kw>
            <kw>high-availability</kw>
            <kw>load-sharing</kw>
            <kw>failover</kw>
            <kw>hot-standby</kw>
        </keywords>
        <abstract><p>This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters.  It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors.  Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ipsecme-ipsec-ha-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC6027</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6028</doc-id>
        <title>Host Identity Protocol (HIP) Multi-Hop Routing Extension</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>source routing</kw>
            <kw>route recording</kw>
            <kw>overlay network</kw>
        </keywords>
        <abstract><p>This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing.  The first extension allows implementing source routing in HIP.  That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse.  The second extension allows a HIP packet to carry and record the list of nodes that forwarded it.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-via-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC6028</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6029</doc-id>
        <title>A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem</title>
        <author>
            <name>I. Rimac</name>
        </author>
        <author>
            <name>V. Hilt</name>
        </author>
        <author>
            <name>M. Tomsu</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>E. Marocco</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Peer-to-Peer</kw>
            <kw>topology estimation</kw>
            <kw>Internet coordinate system</kw>
        </keywords>
        <abstract><p>A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming.  Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology.  As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices.  This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-p2prg-alto-survey-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6029</errata-url>
        <doi>10.17487/RFC6029</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6030</doc-id>
        <title>Portable Symmetric Key Container (PSKC)</title>
        <author>
            <name>P. Hoyer</name>
        </author>
        <author>
            <name>M. Pei</name>
        </author>
        <author>
            <name>S. Machani</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>Symmetric Key</kw>
            <kw>provisioning</kw>
            <kw>AES</kw>
            <kw>3DES</kw>
            <kw>TDES</kw>
            <kw>OTP</kw>
            <kw>Key transport format</kw>
            <kw>key provisioning format</kw>
            <kw>symmetric key protection</kw>
            <kw>symmetric key transport</kw>
            <kw>PIN transport</kw>
            <kw>PIN</kw>
            <kw>provisioning</kw>
            <kw>PIN Policy</kw>
            <kw>key usage policy</kw>
        </keywords>
        <abstract><p>This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules.  For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices.  A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-keyprov-pskc-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>keyprov</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6030</errata-url>
        <doi>10.17487/RFC6030</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6031</doc-id>
        <title>Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines the symmetric key format content type.  It is transport independent.  The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-keyprov-symmetrickeyformat-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>keyprov</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6031</errata-url>
        <doi>10.17487/RFC6031</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6032</doc-id>
        <title>Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CCC</kw>
            <kw>CMS content constraints</kw>
        </keywords>
        <abstract><p>This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package.  It is transport independent.  CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type.  It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-encryptedkeypackagecontenttype-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6032</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6033</doc-id>
        <title>Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type.  Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-encryptedkeypackagecontenttype-algs-02</draft>
        <updated-by>
            <doc-id>RFC6161</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6033</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6034</doc-id>
        <title>Unicast-Prefix-Based IPv4 Multicast Addresses</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract><p>This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol.  The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses.  By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mboned-ipv4-uni-based-mcast-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC6034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6035</doc-id>
        <title>Session Initiation Protocol Event Package for Voice Quality Reporting</title>
        <author>
            <name>A. Pendleton</name>
        </author>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>H. Sinnreich</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>Voice over Internet Protocol</kw>
            <kw>voip</kw>
            <kw>RTP Control Protocol Extended Reports</kw>
            <kw>RTCP-XR</kw>
        </keywords>
        <abstract><p>This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions.  Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector.  A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-rtcp-summary-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6035</errata-url>
        <doi>10.17487/RFC6035</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6036</doc-id>
        <title>Emerging Service Provider Scenarios for IPv6 Deployment</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>isp</kw>
        </keywords>
        <abstract><p>This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services.  They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010.  This document identifies a number of technology gaps, but it does not make recommendations.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-isp-scenarios-00</draft>
        <obsoleted-by>
            <doc-id>RFC9386</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6036</errata-url>
        <doi>10.17487/RFC6036</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6037</doc-id>
        <title>Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs</title>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Cai</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>mvpn</kw>
        </keywords>
        <abstract><p>This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems.  The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF.  However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation.  These differences are pointed out in the document.  This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-rosen-vpn-mcast-15</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6037</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6038</doc-id>
        <title>Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>L. Ciavattone</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Testing</kw>
            <kw>Performance</kw>
            <kw>Metric</kw>
        </keywords>
        <abstract><p>This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-twamp-reflect-octets-09</draft>
        <updates>
            <doc-id>RFC5357</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6038</errata-url>
        <doi>10.17487/RFC6038</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6039</doc-id>
        <title>Issues with Existing Cryptographic Protection Methods for Routing Protocols</title>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>J. Jaeggli</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.</p><p> The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.</p><p> This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-opsec-routing-protocols-crypto-issues-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC6039</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6040</doc-id>
        <title>Tunnelling of Explicit Congestion Notification</title>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Congestion Control and Management</kw>
            <kw>Congestion Notification</kw>
            <kw>Information Security</kw>
            <kw>Tunnelling</kw>
            <kw>Encapsulation</kw>
            <kw>Decapsulation</kw>
            <kw>Protocol</kw>
            <kw>ECN</kw>
            <kw>IPsec</kw>
        </keywords>
        <abstract><p>This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers.  The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported.  Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility.  Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification.  A thorough analysis of the reasoning for these changes and the implications is included.  In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-tunnel-10</draft>
        <updates>
            <doc-id>RFC3168</doc-id>
            <doc-id>RFC4301</doc-id>
            <doc-id>RFC4774</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9601</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6040</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6041</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Applicability Statement</title>
        <author>
            <name>A. Crouch</name>
        </author>
        <author>
            <name>H. Khosravi</name>
        </author>
        <author>
            <name>A. Doria</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Wang</name>
        </author>
        <author>
            <name>K. Ogawa</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>Control Plane</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices.  In this document we describe the applicability of the ForCES model and protocol.  We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-forces-applicability-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC6041</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6042</doc-id>
        <title>Transport Layer Security (TLS) Authorization Using KeyNote</title>
        <author>
            <name>A. Keromytis</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>trust management</kw>
            <kw>authorization</kw>
            <kw>access control</kw>
            <kw>certificates</kw>
        </keywords>
        <abstract><p>This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878.  Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.  Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-keromytis-tls-authz-keynote-07</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6043</doc-id>
        <title>MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>J. Mattsson</name>
        </author>
        <author>
            <name>T. Tian</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>MIKEY</kw>
            <kw>MIKEY-TICKET</kw>
            <kw>KMS</kw>
            <kw>SRTP</kw>
            <kw>IMS</kw>
            <kw>key management</kw>
            <kw>ticket</kw>
        </keywords>
        <abstract><p>The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications.  In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service.  Interest in such deployments is increasing.  Therefore, a set of new MIKEY modes that work well in such scenarios are defined.  The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos.  The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mattsson-mikey-ticket-05</draft>
        <updated-by>
            <doc-id>RFC6309</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6043</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6044</doc-id>
        <title>Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>M. Mohali</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.</p><p> This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.</p><p> Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mohali-diversion-history-info-07</draft>
        <obsoleted-by>
            <doc-id>RFC7544</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6044</errata-url>
        <doi>10.17487/RFC6044</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6045</doc-id>
        <title>Real-time Inter-network Defense (RID)</title>
        <author>
            <name>K. Moriarty</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>Coordinated Incident Response</kw>
            <kw>CSIRT</kw>
            <kw>CIRT</kw>
            <kw>IODEF</kw>
            <kw>Incident Object Exchange</kw>
            <kw>Description Format</kw>
        </keywords>
        <abstract><p>Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.</p><p> RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-moriarty-post-inch-rid-12</draft>
        <obsoleted-by>
            <doc-id>RFC6545</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6045</errata-url>
        <doi>10.17487/RFC6045</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6046</doc-id>
        <title>Transport of Real-time Inter-network Defense (RID) Messages</title>
        <author>
            <name>K. Moriarty</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Coordinate Incident Response</kw>
            <kw>CSIRT</kw>
            <kw>CIRT</kw>
            <kw>IODEF</kw>
            <kw>Incident Object Exchange</kw>
            <kw>Description Format</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises.  This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-moriarty-post-inch-rid-transport-03</draft>
        <obsoleted-by>
            <doc-id>RFC6546</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6046</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6047</doc-id>
        <title>iCalendar Message-Based Interoperability Protocol (iMIP)</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IMIP]</kw>
            <kw>electronic mail</kw>
            <kw>transport</kw>
            <kw>itip</kw>
            <kw>iCalendar Transport-independent Interoperability Protocol</kw>
            <kw>iCalendar Object Model</kw>
        </keywords>
        <abstract><p>This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports.  Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-calsify-rfc2447bis-11</draft>
        <obsoletes>
            <doc-id>RFC2447</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calsify</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6047</errata-url>
        <doi>10.17487/RFC6047</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6048</doc-id>
        <title>Network News Transfer Protocol (NNTP) Additions to LIST Command</title>
        <author>
            <name>J. Elie</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Usenet</kw>
            <kw>NetNews</kw>
            <kw>capabilities</kw>
        </keywords>
        <abstract><p>This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.</p><p> This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-elie-nntp-list-additions-05</draft>
        <updates>
            <doc-id>RFC2980</doc-id>
            <doc-id>RFC3977</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6048</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6049</doc-id>
        <title>Spatial Composition of Metrics</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>E. Stephan</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Measurement</kw>
            <kw>IPPM</kw>
        </keywords>
        <abstract><p>This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics.  This is called "spatial composition" in RFC 2330.  The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others.  The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-spatial-composition-16</draft>
        <updated-by>
            <doc-id>RFC6248</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6049</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6050</doc-id>
        <title>A Session Initiation Protocol (SIP) Extension for the Identification of Services</title>
        <author>
            <name>K. Drage</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>trust domain</kw>
            <kw>service identifier</kw>
        </keywords>
        <abstract><p>This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.</p><p> The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-drage-sipping-service-identification-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6050</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6051</doc-id>
        <title>Rapid Synchronisation of RTP Flows</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>T. Schierl</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>rtcp</kw>
            <kw>rtp control protocol</kw>
            <kw>mcu</kw>
            <kw>multipoint conference units</kw>
            <kw>ssm</kw>
            <kw>source-specific multicast</kw>
        </keywords>
        <abstract><p>This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.</p><p> This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rapid-rtp-sync-12</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC6051</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6052</doc-id>
        <title>IPv6 Addressing of IPv4/IPv6 Translators</title>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>address</kw>
            <kw>prefix</kw>
            <kw>transition</kw>
            <kw>translation</kw>
            <kw>NAT</kw>
            <kw>NAT64</kw>
            <kw>BEHAVE</kw>
            <kw>stateless</kw>
            <kw>stateful</kw>
        </keywords>
        <abstract><p>This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information.  It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate.  Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-address-format-10</draft>
        <updates>
            <doc-id>RFC4291</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6052</errata-url>
        <doi>10.17487/RFC6052</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6053</doc-id>
        <title>Implementation Report for Forwarding and Control Element Separation (ForCES)</title>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>K. Ogawa</name>
        </author>
        <author>
            <name>W. Wang</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Stream Control Transmission Protocol-based Transport Mapping Layer</kw>
            <kw>SCTP TML</kw>
            <kw>forces Model</kw>
        </keywords>
        <abstract><p>Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.</p><p> This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-forces-implementation-report-02</draft>
        <updated-by>
            <doc-id>RFC6984</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC6053</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6054</doc-id>
        <title>Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES).  Counter modes use a counter, which is typically assumed to be incremented by a single sender.  This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-ipsec-group-counter-modes-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <doi>10.17487/RFC6054</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6055</doc-id>
        <title>IAB Thoughts on Encodings for Internationalized Domain Names</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Unicode</kw>
            <kw>UTF-8,</kw>
        </keywords>
        <abstract><p>This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm.  It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.</p></abstract>
        <draft>draft-iab-idn-encoding-04</draft>
        <updates>
            <doc-id>RFC2130</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6055</errata-url>
        <doi>10.17487/RFC6055</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6056</doc-id>
        <title>Recommendations for Transport-Protocol Port Randomization</title>
        <author>
            <name>M. Larsen</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>transmission control protocl</kw>
            <kw>blind attacks</kw>
        </keywords>
        <abstract><p>During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols.  The consequences of these attacks range from throughput reduction to broken connections or data corruption.  These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked.  This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced.  While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead.  The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers).  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-tsvwg-port-randomization-09</draft>
        <is-also>
            <doc-id>BCP0156</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6056</errata-url>
        <doi>10.17487/RFC6056</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6057</doc-id>
        <title>Comcast's Protocol-Agnostic Congestion Management System</title>
        <author>
            <name>C. Bastian</name>
        </author>
        <author>
            <name>T. Klieber</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>J. Mills</name>
        </author>
        <author>
            <name>R. Woundy</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract><p>This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S.  Comcast completed deployment of this congestion management system on December 31, 2008.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-livingood-woundy-congestion-mgmt-09</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6057</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6058</doc-id>
        <title>Transient Binding for Proxy Mobile IPv6</title>
        <author>
            <name>M. Liebsch</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Muhanna</name>
        </author>
        <author>
            <name>O. Blume</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>PMIP</kw>
            <kw>handover optimization</kw>
            <kw>handover delay</kw>
            <kw>tBCE</kw>
            <kw>late path switch</kw>
            <kw>forwarding</kw>
            <kw>make-before-break</kw>
            <kw>dual radio handover</kw>
            <kw>single radio handover</kw>
            <kw>transient binding cache entry</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover.  This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces.  The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described.  The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mipshop-transient-bce-pmipv6-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mipshop</wg_acronym>
        <doi>10.17487/RFC6058</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6059</doc-id>
        <title>Simple Procedures for Detecting Network Attachment in IPv6</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>G. Daley</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNA</kw>
            <kw>DNAv6</kw>
            <kw>ND</kw>
            <kw>IPv6 neighbor discovery</kw>
            <kw>neighbor discovery</kw>
            <kw>send</kw>
            <kw>secure neighbor discovery</kw>
            <kw>DHCPv6</kw>
            <kw>stateless autoconfiguration</kw>
            <kw>change detection</kw>
            <kw>movement detection</kw>
            <kw>DNAv4</kw>
            <kw>link detection</kw>
            <kw>mobility</kw>
        </keywords>
        <abstract><p>Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network.  This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dna-simple-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dna</wg_acronym>
        <doi>10.17487/RFC6059</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6060</doc-id>
        <title>Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)</title>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>A. Takacs</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IEEE data plane</kw>
        </keywords>
        <abstract><p>This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE).  The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections.  This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ethernet-pbb-te-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6060</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6061</doc-id>
        <title>Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA).  NENA defines and manages resources that utilize this URN model.  Management activities for these and other resource types are provided by the NENA Registry System (NRS).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-rosen-urn-nena-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6061</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6062</doc-id>
        <title>Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations</title>
        <author>
            <name>S. Perreault</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>TURN</kw>
            <kw>STUN</kw>
        </keywords>
        <abstract><p>This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal.  This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers.  TURN and this extension both purposefully restrict the ways in which the relayed address can be used.  In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-turn-tcp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6062</errata-url>
        <doi>10.17487/RFC6062</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6063</doc-id>
        <title>Dynamic Symmetric Key Provisioning Protocol (DSKPP)</title>
        <author>
            <name>A. Doherty</name>
        </author>
        <author>
            <name>M. Pei</name>
        </author>
        <author>
            <name>S. Machani</name>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>105</page-count>
        <keywords>
            <kw>Cryptographic module</kw>
            <kw>Cryptographic Token</kw>
            <kw>key initialization</kw>
            <kw>credentials</kw>
            <kw>online provisioning</kw>
        </keywords>
        <abstract><p>The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.</p><p> Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-keyprov-dskpp-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>keyprov</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6063</errata-url>
        <doi>10.17487/RFC6063</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6064</doc-id>
        <title>SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>P. Frojdh</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>3GPP</kw>
            <kw>PSS</kw>
            <kw>MBMS</kw>
            <kw>SDP</kw>
            <kw>RTSP</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions.  This document provides information about these extensions and registers the RTSP and SDP extensions with IANA.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-westerlund-mmusic-3gpp-sdp-rtsp-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6064</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6065</doc-id>
        <title>Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings</title>
        <author>
            <name>K. Narayan</name>
        </author>
        <author>
            <name>D. Nelson</name>
        </author>
        <author>
            <name>R. Presuhn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Security</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>RADIUS</kw>
            <kw>AAA</kw>
            <kw>VACM</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-radius-vacm-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <doi>10.17487/RFC6065</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6066</doc-id>
        <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>server_name</kw>
            <kw>max_fragment_length</kw>
            <kw>client_certificate_url</kw>
            <kw>trusted_ca_keys</kw>
            <kw>truncated_hmac</kw>
            <kw>status_request</kw>
        </keywords>
        <abstract><p>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2".  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-rfc4366-bis-12</draft>
        <obsoletes>
            <doc-id>RFC4366</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8446</doc-id>
            <doc-id>RFC8449</doc-id>
            <doc-id>RFC9325</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6066</errata-url>
        <doi>10.17487/RFC6066</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6067</doc-id>
        <title>BCP 47 Extension U</title>
        <author>
            <name>M. Davis</name>
        </author>
        <author>
            <name>A. Phillips</name>
        </author>
        <author>
            <name>Y. Umaoka</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>locale</kw>
            <kw>bcp 47</kw>
        </keywords>
        <abstract><p>This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-davis-u-langtag-ext-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6067</errata-url>
        <doi>10.17487/RFC6067</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6068</doc-id>
        <title>The 'mailto' URI Scheme</title>
        <author>
            <name>M. Duerst</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>J. Zawinski</name>
        </author>
        <date>
            <month>October</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>mailto</kw>
            <kw>email address</kw>
            <kw>URI scheme</kw>
            <kw>IRI</kw>
        </keywords>
        <abstract><p>This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail.  It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-duerst-mailto-bis-10</draft>
        <obsoletes>
            <doc-id>RFC2368</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6068</errata-url>
        <doi>10.17487/RFC6068</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6069</doc-id>
        <title>Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)</title>
        <author>
            <name>A. Zimmermann</name>
        </author>
        <author>
            <name>A. Hannemann</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Internet Control Message Protocol (ICMP)</kw>
            <kw>Retranmission Timeout (RTO)</kw>
        </keywords>
        <abstract><p>Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.</p><p> This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-lcd-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6069</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6070</doc-id>
        <title>PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-josefsson-pbkdf2-test-vectors-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6070</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6071</doc-id>
        <title>IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap</title>
        <author>
            <name>S. Frankel</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>privacy</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.</p><p> This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."</p><p> The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ipsecme-roadmap-10</draft>
        <obsoletes>
            <doc-id>RFC2411</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC6071</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6072</doc-id>
        <title>Certificate Management Service for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>J. Fischl</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>credential service</kw>
            <kw>aor</kw>
            <kw>address of record</kw>
        </keywords>
        <abstract><p>This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users.  This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate.  The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-certs-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6072</errata-url>
        <doi>10.17487/RFC6072</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6073</doc-id>
        <title>Segmented Pseudowire</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>M. Aissaoui</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>pws</kw>
            <kw>psn</kw>
            <kw>packet switched network</kw>
            <kw>pw control plane domain</kw>
        </keywords>
        <abstract><p>This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW.  The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point.  The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-segmented-pw-18</draft>
        <updated-by>
            <doc-id>RFC6723</doc-id>
            <doc-id>RFC7267</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6073</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6074</doc-id>
        <title>Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>V. Radoaca</name>
        </author>
        <author>
            <name>W. Luo</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
        </keywords>
        <abstract><p>Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities.  Once configured, the provisioning information is distributed by a "discovery process".  When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN.  This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model.  It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP).  It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]</p></abstract>
        <draft>draft-ietf-l2vpn-signaling-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC6074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6075</doc-id>
        <title>The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry</title>
        <author>
            <name>D. Cridland</name>
        </author>
        <date>
            <month>December</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>annotate</kw>
            <kw>metadata</kw>
        </keywords>
        <abstract><p>The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols.  This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-cridland-acap-vendor-registry-02</draft>
        <updates>
            <doc-id>RFC2244</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6075</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6076</doc-id>
        <title>Basic Telephony SIP End-to-End Performance Metrics</title>
        <author>
            <name>D. Malas</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Benchmarking</kw>
            <kw>Lab</kw>
            <kw>Test</kw>
            <kw>Time</kw>
            <kw>Measurement</kw>
            <kw>Service</kw>
            <kw>Session</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments.  The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pmol-sip-perf-metrics-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>pmol</wg_acronym>
        <doi>10.17487/RFC6076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6077</doc-id>
        <title>Open Research Issues in Internet Congestion Control</title>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>M. Scharf</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>Signalling</kw>
            <kw>Performance</kw>
            <kw>Robustness</kw>
            <kw>Fairness</kw>
            <kw>Stability</kw>
            <kw>Misbehaviour</kw>
            <kw>Architecture</kw>
        </keywords>
        <abstract><p>This document describes some of the open problems in Internet congestion control that are known today.  This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years.  These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-iccrg-welzl-congestion-control-open-research-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6077</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6078</doc-id>
        <title>Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Melen</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>HIP DATA</kw>
        </keywords>
        <abstract><p>This document defines a new Host Identity Protocol (HIP) packet type called DATA.  HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-hiccups-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC6078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6079</doc-id>
        <title>HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>P. Nikander</name>
        </author>
        <author>
            <name>J. Hautakorpi</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks.  This framework uses HIP to perform connection management.  Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP.  These protocols are loosely referred to as "peer protocols".  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-bone-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC6079</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6080</doc-id>
        <title>A Framework for Session Initiation Protocol User Agent Profile Delivery</title>
        <author>
            <name>D. Petrie</name>
        </author>
        <author>
            <name>S. Channabasappa</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Configuration</kw>
            <kw>Framework</kw>
            <kw>User Agent</kw>
            <kw>profile</kw>
        </keywords>
        <abstract><p>This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments.  The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention.  The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications.  As part of this framework, a new SIP event package is defined for notification of profile changes.  The framework provides minimal data retrieval options to ensure interoperability.  The framework does not include specification of the profile data within its scope. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-config-framework-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC6080</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6081</doc-id>
        <title>Teredo Extensions</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>NAT</kw>
            <kw>traversal</kw>
            <kw>transition</kw>
            <kw>translation</kw>
            <kw>translator</kw>
        </keywords>
        <abstract><p>This document specifies a set of extensions to the Teredo protocol.  These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-thaler-v6ops-teredo-extensions-08</draft>
        <updates>
            <doc-id>RFC4380</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6081</errata-url>
        <doi>10.17487/RFC6081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6082</doc-id>
        <title>Deprecating Unicode Language Tag Characters: RFC 2482 is Historic</title>
        <author>
            <name>K. Whistler</name>
        </author>
        <author>
            <name>G. Adams</name>
        </author>
        <author>
            <name>M. Duerst</name>
        </author>
        <author>
            <name>R. Presuhn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>characters</kw>
            <kw>strings</kw>
            <kw>ASCII</kw>
        </keywords>
        <abstract><p>RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML.  The Unicode Consortium has deprecated that facility and strongly recommends against its use.  RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-presuhn-rfc2482-historic-02</draft>
        <obsoletes>
            <doc-id>RFC2482</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6082</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6083</doc-id>
        <title>Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Seggelmann</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).</p><p> DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.</p><p> Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-dtls-for-sctp-06</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6083</errata-url>
        <doi>10.17487/RFC6083</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6084</doc-id>
        <title>General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>X. Fu</name>
        </author>
        <author>
            <name>C. Dickmann</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Multihoming</kw>
            <kw>Signaling</kw>
            <kw>Partial Reliability</kw>
        </keywords>
        <abstract><p>The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation.  This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS).  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-nsis-ntlp-sctp-15</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>nsis</wg_acronym>
        <doi>10.17487/RFC6084</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6085</doc-id>
        <title>Address Mapping of IPv6 Multicast Packets on Ethernet</title>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>W. Dec</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
        </keywords>
        <abstract><p>When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address.  This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gundavelli-v6ops-l2-unicast-06</draft>
        <updates>
            <doc-id>RFC2464</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6085</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6086</doc-id>
        <title>Session Initiation Protocol (SIP) INFO Method and Package Framework</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Info Package</kw>
            <kw>Info-Package</kw>
            <kw>Recv-Info</kw>
        </keywords>
        <abstract><p>This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism.  This document obsoletes RFC 2976.  For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-info-events-10</draft>
        <obsoletes>
            <doc-id>RFC2976</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6086</errata-url>
        <doi>10.17487/RFC6086</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6087</doc-id>
        <title>Guidelines for Authors and Reviewers of YANG Data Model Documents</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>NETMOD</kw>
            <kw>NETCONF</kw>
            <kw>XML</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules.  Applicable portions may be used as a basis for reviews of other YANG data model documents.  Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-netmod-yang-usage-11</draft>
        <obsoleted-by>
            <doc-id>RFC8407</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC6087</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6088</doc-id>
        <title>Traffic Selectors for Flow Bindings</title>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>G. Giarreta</name>
        </author>
        <author>
            <name>H. Soliman</name>
        </author>
        <author>
            <name>N. Montavont</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Mobile IPv6</kw>
            <kw>Binary Traffic Selectors</kw>
        </keywords>
        <abstract><p>This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mext-binary-ts-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC6088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6089</doc-id>
        <title>Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support</title>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>H. Soliman</name>
        </author>
        <author>
            <name>N. Montavont</name>
        </author>
        <author>
            <name>G. Giaretta</name>
        </author>
        <author>
            <name>K. Kuladinithi</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Flow Identification</kw>
            <kw>Flow Summary</kw>
            <kw>Binding Reference</kw>
            <kw>Traffic Selector</kw>
            <kw>Flow Binding Entry</kw>
        </keywords>
        <abstract><p>This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address.  These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK]</p></abstract>
        <draft>draft-ietf-mext-flow-binding-11</draft>
        <updates>
            <doc-id>RFC5648</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC6089</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6090</doc-id>
        <title>Fundamental Elliptic Curve Cryptography Algorithms</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>K. Igoe</name>
        </author>
        <author>
            <name>M. Salter</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>ECC</kw>
        </keywords>
        <abstract><p>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier.  These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years.  Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mcgrew-fundamental-ecc-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6090</errata-url>
        <doi>10.17487/RFC6090</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6091</doc-id>
        <title>Using OpenPGP Keys for Transport Layer Security (TLS) Authentication</title>
        <author>
            <name>N. Mavrogiannopoulos</name>
        </author>
        <author>
            <name>D. Gillmor</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Certificate type negotiation</kw>
            <kw>tls handshake protocol</kw>
            <kw>handshake</kw>
        </keywords>
        <abstract><p>This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS.  It also defines the registry for non-X.509 certificate types.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mavrogiannopoulos-rfc5081bis-09</draft>
        <obsoletes>
            <doc-id>RFC5081</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6091</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6092</doc-id>
        <title>Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service</title>
        <author>
            <name>J. Woodyatt</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>cpe</kw>
            <kw>firewall</kw>
            <kw>filter</kw>
        </keywords>
        <abstract><p>This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-cpe-simple-security-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6092</errata-url>
        <doi>10.17487/RFC6092</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6093</doc-id>
        <title>On the Implementation of the TCP Urgent Mechanism</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Transmission Control Protocol</kw>
        </keywords>
        <abstract><p>This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications.  This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-urgent-data-07</draft>
        <obsoleted-by>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0793</doc-id>
            <doc-id>RFC1011</doc-id>
            <doc-id>RFC1122</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6093</errata-url>
        <doi>10.17487/RFC6093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6094</doc-id>
        <title>Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IGP security</kw>
        </keywords>
        <abstract><p>The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.</p><p> To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.</p><p> Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.</p><p> This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-opsec-igp-crypto-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC6094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6095</doc-id>
        <title>Extending YANG with Language Abstractions</title>
        <author>
            <name>B. Linowski</name>
        </author>
        <author>
            <name>M. Ersue</name>
        </author>
        <author>
            <name>S. Kuryla</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>model</kw>
            <kw>complex-type</kw>
            <kw>Complex Types</kw>
            <kw>Typed Instance</kw>
            <kw>Resource Model</kw>
            <kw>Inheritance</kw>
            <kw>class</kw>
        </keywords>
        <abstract><p>YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF.  This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-linowski-netmod-yang-abstract-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6095</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6096</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Chunk Flags Registration</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <date>
            <month>January</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP).  It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types.  It does not change SCTP in any other way. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-chunk-flags-02</draft>
        <obsoleted-by>
            <doc-id>RFC9260</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4960</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6096</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6097</doc-id>
        <title>Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6</title>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PMIPv6</kw>
            <kw>3GPP</kw>
            <kw>DNS</kw>
            <kw>AAA</kw>
        </keywords>
        <abstract><p>Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain.  The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway.  This document describes several possible dynamic Local Mobility Anchor discovery solutions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-netlmm-lma-discovery-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netlmm</wg_acronym>
        <doi>10.17487/RFC6097</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6098</doc-id>
        <title>Generic Notification Message for Mobile IPv4</title>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>H. Levkowetz</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>B. Haley</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>mipv4</kw>
        </keywords>
        <abstract><p>This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-generic-notification-message-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC6098</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6099</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6100</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6101</doc-id>
        <title>The Secure Sockets Layer (SSL) Protocol Version 3.0</title>
        <author>
            <name>A. Freier</name>
        </author>
        <author>
            <name>P. Karlton</name>
        </author>
        <author>
            <name>P. Kocher</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>Transport layer security</kw>
        </keywords>
        <abstract><p>This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.</p><p> This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that 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. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-mavrogiannopoulos-ssl-version3-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6101</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6102</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6103</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6104</doc-id>
        <title>Rogue IPv6 Router Advertisement Problem Statement</title>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>RA</kw>
            <kw>rogue ra</kw>
        </keywords>
        <abstract><p>When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network.  This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information.  However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network.  In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem.  We focus on the unintended causes of rogue RAs in the text.  The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-rogue-ra-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6104</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6105</doc-id>
        <title>IPv6 Router Advertisement Guard</title>
        <author>
            <name>E. Levy-Abegnoli</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>C. Popoviciu</name>
        </author>
        <author>
            <name>J. Mohacsi</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SEcure Neighbor Discovery</kw>
            <kw>Stateless Address Autoconfiguration</kw>
        </keywords>
        <abstract><p>Routed protocols are often susceptible to spoof attacks.  The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy.  This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-ra-guard-08</draft>
        <updated-by>
            <doc-id>RFC7113</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6105</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6106</doc-id>
        <title>IPv6 Router Advertisement Options for DNS Configuration</title>
        <author>
            <name>J. Jeong</name>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>L. Beloeil</name>
        </author>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <date>
            <month>November</month>
            <year>2010</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNS Service</kw>
            <kw>DNS Option</kw>
            <kw>Recursive DNS Server Address</kw>
            <kw>DNS Search List</kw>
            <kw>Stateless Autoconfiguration</kw>
        </keywords>
        <abstract><p>This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-dns-options-bis-08</draft>
        <obsoletes>
            <doc-id>RFC5006</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8106</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6106</errata-url>
        <doi>10.17487/RFC6106</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6107</doc-id>
        <title>Procedures for Dynamically Signaled Hierarchical Label Switched Paths</title>
        <author>
            <name>K. Shiomoto</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>TE links</kw>
            <kw>Bundled links</kw>
            <kw>GMPLS</kw>
            <kw>dynamically provisioned networks</kw>
        </keywords>
        <abstract><p>Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.</p><p> Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-lsp-hierarchy-bis-08</draft>
        <updates>
            <doc-id>RFC3477</doc-id>
            <doc-id>RFC4206</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6107</errata-url>
        <doi>10.17487/RFC6107</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6108</doc-id>
        <title>Comcast's Web Notification System Design</title>
        <author>
            <name>C. Chung</name>
        </author>
        <author>
            <name>A. Kasyanov</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>N. Mody</name>
        </author>
        <author>
            <name>B. Van Lieu</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>bot remediation</kw>
            <kw>bot notification</kw>
        </keywords>
        <abstract><p>The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP).  Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection.  There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology.  In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-livingood-web-notification-09</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6108</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6109</doc-id>
        <title>La Posta Elettronica Certificata - Italian Certified Electronic Mail</title>
        <author>
            <name>C. Petrucci</name>
        </author>
        <author>
            <name>F. Gennai</name>
        </author>
        <author>
            <name>A. Shahin</name>
        </author>
        <author>
            <name>A. Vinciarelli</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>PEC</kw>
            <kw>Registered mail</kw>
            <kw>Return receipt</kw>
            <kw>Digitally signed email</kw>
            <kw>Digitally signed notification</kw>
            <kw>MIME</kw>
            <kw>SMIME</kw>
        </keywords>
        <abstract><p>Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing.</p><p> The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-gennai-smime-cnipa-pec-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6109</errata-url>
        <doi>10.17487/RFC6109</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6110</doc-id>
        <title>Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content</title>
        <author>
            <name>L. Lhotka</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>DSDL</kw>
            <kw>validation</kw>
            <kw>RELAX NG</kw>
            <kw>Schematron</kw>
            <kw>DSRL</kw>
        </keywords>
        <abstract><p>This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757.  The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL).  The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc.  Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netmod-dsdl-map-10</draft>
        <updated-by>
            <doc-id>RFC7952</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6110</errata-url>
        <doi>10.17487/RFC6110</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6111</doc-id>
        <title>Additional Kerberos Naming Constraints</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>principal names</kw>
            <kw>realm names</kw>
        </keywords>
        <abstract><p>This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-naming-07</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6112</doc-id>
        <title>Anonymity Support for Kerberos</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>kerberos realm</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm.  It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC).  This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-anon-12</draft>
        <obsoleted-by>
            <doc-id>RFC8062</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4120</doc-id>
            <doc-id>RFC4121</doc-id>
            <doc-id>RFC4556</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6112</errata-url>
        <doi>10.17487/RFC6112</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6113</doc-id>
        <title>A Generalized Framework for Kerberos Pre-Authentication</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
        </keywords>
        <abstract><p>Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.</p><p> This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.</p><p> This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-preauth-framework-17</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6113</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6114</doc-id>
        <title>The 128-Bit Blockcipher CLEFIA</title>
        <author>
            <name>M. Katagi</name>
        </author>
        <author>
            <name>S. Moriai</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>security</kw>
            <kw>lightweight cryptography</kw>
            <kw>encryption algorithm</kw>
        </keywords>
        <abstract><p>This document describes the specification of the blockcipher CLEFIA.  CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES).  The algorithm of CLEFIA was published in 2007, and its security has been scrutinized in the public community.  CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES.  Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware.  CLEFIA will be of benefit to the Internet, which will be connected to more distributed and constrained devices.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-katagi-clefia-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6114</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6115</doc-id>
        <title>Recommendation for a Routing Architecture</title>
        <author>
            <name>T. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <abstract><p>It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering.  This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet.  To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs.  This document is a product of the Routing Research Group.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-rrg-recommendation-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6115</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6116</doc-id>
        <title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>E.164</kw>
            <kw>NAPTR</kw>
            <kw>dynamic delegation discovery system</kw>
            <kw>e164.arpa</kw>
        </keywords>
        <abstract><p>This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup.  This document also describes how the DNS can be used to identify the services associated with an E.164 number.  This document obsoletes RFC 3761. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-3761bis-09</draft>
        <obsoletes>
            <doc-id>RFC3761</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC6116</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6117</doc-id>
        <title>IANA Registration of Enumservices: Guide, Template, and IANA Considerations</title>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-enumservices-guide-22</draft>
        <obsoletes>
            <doc-id>RFC3761</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC6117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6118</doc-id>
        <title>Update of Legacy IANA Registrations of Enumservices</title>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-enum-enumservices-transition-06</draft>
        <updates>
            <doc-id>RFC3762</doc-id>
            <doc-id>RFC3764</doc-id>
            <doc-id>RFC3953</doc-id>
            <doc-id>RFC4143</doc-id>
            <doc-id>RFC4002</doc-id>
            <doc-id>RFC4238</doc-id>
            <doc-id>RFC4355</doc-id>
            <doc-id>RFC4415</doc-id>
            <doc-id>RFC4769</doc-id>
            <doc-id>RFC4969</doc-id>
            <doc-id>RFC4979</doc-id>
            <doc-id>RFC5028</doc-id>
            <doc-id>RFC5278</doc-id>
            <doc-id>RFC5333</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC6118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6119</doc-id>
        <title>IPv6 Traffic Engineering in IS-IS</title>
        <author>
            <name>J. Harrison</name>
        </author>
        <author>
            <name>J. Berger</name>
        </author>
        <author>
            <name>M. Bartlett</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol.  This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-ipv6-te-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC6119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6120</doc-id>
        <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>211</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>Jabber</kw>
            <kw>Messaging</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
            <kw>Extensible Markup Language</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.  This document obsoletes RFC 3920. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xmpp-3920bis-22</draft>
        <obsoletes>
            <doc-id>RFC3920</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7590</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6120</errata-url>
        <doi>10.17487/RFC6120</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6121</doc-id>
        <title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>114</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>Jabber</kw>
            <kw>IM</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
            <kw>XML</kw>
            <kw>Extensible Markup Language</kw>
        </keywords>
        <abstract><p>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779.  This document obsoletes RFC 3921. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xmpp-3921bis-20</draft>
        <obsoletes>
            <doc-id>RFC3921</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6121</errata-url>
        <doi>10.17487/RFC6121</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6122</doc-id>
        <title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>Messaging</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
            <kw>Extensible Markup Language</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters.  This document updates RFC 3920. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xmpp-address-09</draft>
        <obsoleted-by>
            <doc-id>RFC7622</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3920</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6122</errata-url>
        <doi>10.17487/RFC6122</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6123</doc-id>
        <title>Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.</p><p> The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.</p><p> Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-ietf-pce-manageability-requirements-11</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC6123</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6124</doc-id>
        <title>An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>password-based authentication</kw>
            <kw>mutual authentication</kw>
            <kw>password-based cryptography</kw>
            <kw>password authenticated key exchange</kw>
            <kw>weak password authentication</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms.  This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol.  This method provides mutual authentication through the use of a short, easy to remember password.  Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks.  Neither does it require the availability of public-key certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-sheffer-emu-eap-eke-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6124</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6125</doc-id>
        <title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>J. Hodges</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
        </keywords>
        <abstract><p>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS).  This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-saintandre-tls-server-id-check-14</draft>
        <obsoleted-by>
            <doc-id>RFC9525</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6125</errata-url>
        <doi>10.17487/RFC6125</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6126</doc-id>
        <title>The Babel Routing Protocol</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <abstract><p>Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-chroboczek-babel-routing-protocol-05</draft>
        <obsoleted-by>
            <doc-id>RFC8966</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7298</doc-id>
            <doc-id>RFC7557</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6126</errata-url>
        <doi>10.17487/RFC6126</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6127</doc-id>
        <title>IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>address depletion</kw>
            <kw>translation</kw>
            <kw>NAT-PT</kw>
            <kw>dual-stack</kw>
            <kw>Softwire</kw>
            <kw>Behave</kw>
            <kw>NAT</kw>
            <kw>NAT444</kw>
        </keywords>
        <abstract><p>When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.</p><p> This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-arkko-townsley-coexistence-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6128</doc-id>
        <title>RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions</title>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic.  In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description.  However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description.  Deriving the RTCP port from the "m=" line imposes an unnecessary restriction.  This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtcp-port-for-ssm-04</draft>
        <updates>
            <doc-id>RFC5760</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC6128</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6129</doc-id>
        <title>The 'application/tei+xml' Media Type</title>
        <author>
            <name>L. Romary</name>
        </author>
        <author>
            <name>S. Lundberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Text Encoding Initiative</kw>
            <kw>xml</kw>
            <kw>text encoding</kw>
            <kw>text representation</kw>
            <kw>MIME type</kw>
        </keywords>
        <abstract><p>This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding and Interchange guidelines.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-lundberg-app-tei-xml-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6129</errata-url>
        <doi>10.17487/RFC6129</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6130</doc-id>
        <title>Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>J. Dean</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>OLSRv2</kw>
            <kw>packetbb</kw>
            <kw>Routing Protocol</kw>
            <kw>NHDP</kw>
            <kw>ad hoc network</kw>
            <kw>bi-directional</kw>
            <kw>2-hop discovery</kw>
            <kw>Wireless</kw>
            <kw>SMF</kw>
        </keywords>
        <abstract><p>This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-manet-nhdp-15</draft>
        <updated-by>
            <doc-id>RFC7183</doc-id>
            <doc-id>RFC7188</doc-id>
            <doc-id>RFC7466</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6130</errata-url>
        <doi>10.17487/RFC6130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6131</doc-id>
        <title>Sieve Vacation Extension: "Seconds" Parameter</title>
        <author>
            <name>R. George</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>email</kw>
            <kw>filters</kw>
            <kw>auto-replies</kw>
        </keywords>
        <abstract><p>This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-vacation-seconds-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6131</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6132</doc-id>
        <title>Sieve Notification Using Presence Information</title>
        <author>
            <name>R. George</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>email</kw>
            <kw>filters</kw>
            <kw>context</kw>
            <kw>status</kw>
        </keywords>
        <abstract><p>This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-notify-presence-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6132</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6133</doc-id>
        <title>Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality</title>
        <author>
            <name>R. George</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sieve-autoreply-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6134</doc-id>
        <title>Sieve Extension: Externally Stored Lists</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.</p><p> This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-external-lists-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6134</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6135</doc-id>
        <title>An Alternative Connection Model for the Message Session Relay Protocol (MSRP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>S. Blau</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>comedia</kw>
            <kw>comedia-tls</kw>
            <kw>relay</kw>
            <kw>SBC</kw>
        </keywords>
        <abstract><p>This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection.  The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-msrp-acm-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC6135</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6136</doc-id>
        <title>Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Mohan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM).  The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels.  This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS).  Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-l2vpn-oam-req-frmk-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC6136</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6137</doc-id>
        <title>The Network Trouble Ticket Data Model (NTTDM)</title>
        <author>
            <name>D. Zisiadis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Kopsidas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Tsavli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Cessieux</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>Grid</kw>
            <kw>Management</kw>
            <kw>EGEE</kw>
        </keywords>
        <abstract><p>Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent, and disseminate TT information in different formats.</p><p> As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-dzis-nwg-nttdm-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6137</errata-url>
        <doi>10.17487/RFC6137</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6138</doc-id>
        <title>LDP IGP Synchronization for Broadcast Networks</title>
        <author>
            <name>S. Kini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Lu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not.  If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer.  When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network.  This document describes a mechanism to address that use-case without dropping traffic.  The mechanism does not introduce any protocol message changes.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-ldp-igp-sync-bcast-06</draft>
        <updates>
            <doc-id>RFC5443</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6138</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6139</doc-id>
        <title>Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios</title>
        <author>
            <name>S. Russert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Fleischman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Templin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>Encapsulation</kw>
            <kw>Tunnel</kw>
            <kw>Architecture</kw>
            <kw>Scalability</kw>
            <kw>Mobility</kw>
            <kw>MANET</kw>
            <kw>Security</kw>
            <kw>IPv6</kw>
            <kw>Aerospace</kw>
            <kw>IRON</kw>
            <kw>VET</kw>
            <kw>SEAL</kw>
            <kw>ISATAP</kw>
        </keywords>
        <abstract><p>"Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing.  It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security.  This document describes a series of use cases in order to showcase the architectural capabilities.  It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-russert-rangers-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6139</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6140</doc-id>
        <title>Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Bulk Registration</kw>
            <kw>Implicit Registration</kw>
            <kw>GIN</kw>
            <kw>PBX</kw>
            <kw>SSP</kw>
            <kw>SIP-PBX</kw>
        </keywords>
        <abstract><p>This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs).  In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts.  This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique.  This document therefore focuses on this use case. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-martini-gin-13</draft>
        <updates>
            <doc-id>RFC3680</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>martini</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6140</errata-url>
        <doi>10.17487/RFC6140</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6141</doc-id>
        <title>Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>Y. Gao</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>re-INVITE</kw>
            <kw>offer/answer</kw>
            <kw>rollback</kw>
        </keywords>
        <abstract><p>The procedures for handling SIP re-INVITEs are described in RFC 3261.  Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues.  In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE.  Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-reinvite-08</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC6141</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6142</doc-id>
        <title>ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP</title>
        <author>
            <name>A. Moise</name>
        </author>
        <author>
            <name>J. Brodkin</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Advanced Metering Infrastructure</kw>
            <kw>ami</kw>
            <kw>application layer message</kw>
        </keywords>
        <abstract><p>This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.</p><p> This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-c1222-transport-over-ip-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6142</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6143</doc-id>
        <title>The Remote Framebuffer Protocol</title>
        <author>
            <name>T. Richardson</name>
        </author>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>vnc</kw>
            <kw>rfb</kw>
            <kw>remote framebuffer</kw>
            <kw>remote GUI</kw>
        </keywords>
        <abstract><p>RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer.  Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications.  This document describes the protocol used to communicate between an RFB client and RFB server.  RFB is the protocol used in VNC.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-levine-rfb-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6143</errata-url>
        <doi>10.17487/RFC6143</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6144</doc-id>
        <title>Framework for IPv4/IPv6 Translation</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>K. Yin</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>stateless translation</kw>
            <kw>stateful translation</kw>
        </keywords>
        <abstract><p>This note describes a framework for IPv4/IPv6 translation.  This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-behave-v6v4-framework-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC6144</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6145</doc-id>
        <title>IP/ICMP Translation Algorithm</title>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>SIIT]</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>control</kw>
            <kw>message</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>Stateless IP/ICMP Translation Algorithm,</kw>
        </keywords>
        <abstract><p>This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers).  This document obsoletes RFC 2765. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-v6v4-xlate-23</draft>
        <obsoletes>
            <doc-id>RFC2765</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7915</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC6791</doc-id>
            <doc-id>RFC7757</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6145</errata-url>
        <doi>10.17487/RFC6145</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6146</doc-id>
        <title>Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <author>
            <name>I. van Beijnum</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>NAT64</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP.  One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients.  When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server.</p></abstract>
        <draft>draft-ietf-behave-v6v4-xlate-stateful-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6146</errata-url>
        <doi>10.17487/RFC6146</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6147</doc-id>
        <title>DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>A. Sullivan</name>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <author>
            <name>I. van Beijnum</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>AAAA</kw>
        </keywords>
        <abstract><p>DNS64 is a mechanism for synthesizing AAAA records from A records.  DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs.  This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-dns64-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6147</errata-url>
        <doi>10.17487/RFC6147</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6148</doc-id>
        <title>DHCPv4 Lease Query by Relay Agent Remote ID</title>
        <author>
            <name>P. Kurapati</name>
        </author>
        <author>
            <name>R. Desetti</name>
        </author>
        <author>
            <name>B. Joshi</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract><p>Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server.  This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding.  RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost.  The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients.  In certain scenarios, this model is not scalable.  This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-leasequery-by-remote-id-09</draft>
        <updates>
            <doc-id>RFC4388</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6148</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6149</doc-id>
        <title>MD2 to Historic Status</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>L. Chen</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>This document retires MD2 and discusses the reasons for doing so.  This document moves RFC 1319 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-md2-to-historic-10</draft>
        <obsoletes>
            <doc-id>RFC1319</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6149</errata-url>
        <doi>10.17487/RFC6149</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6150</doc-id>
        <title>MD4 to Historic Status</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>L. Chen</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MD4</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so.  This document moves RFC 1320 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-md4-to-historic-11</draft>
        <obsoletes>
            <doc-id>RFC1320</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6150</errata-url>
        <doi>10.17487/RFC6150</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6151</doc-id>
        <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>L. Chen</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>signature</kw>
            <kw>eneryption</kw>
            <kw>ipsec</kw>
            <kw>Message Digest</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document updates the security considerations for the MD5 message digest algorithm.  It also updates the security considerations for HMAC-MD5.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-md5-seccon-update-08</draft>
        <updates>
            <doc-id>RFC1321</doc-id>
            <doc-id>RFC2104</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6151</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6152</doc-id>
        <title>SMTP Service Extension for 8-bit MIME Transport</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>D. Crocker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>simple mail transfer</kw>
        </keywords>
        <abstract><p>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]</p></abstract>
        <draft>draft-ietf-yam-rfc1652bis-03</draft>
        <obsoletes>
            <doc-id>RFC1652</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0071</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>yam</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6152</errata-url>
        <doi>10.17487/RFC6152</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6153</doc-id>
        <title>DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery</title>
        <author>
            <name>S. Das</name>
        </author>
        <author>
            <name>G. Bajko</name>
        </author>
        <date>
            <month>February</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Dynamic Host Configuration Protocol</kw>
        </keywords>
        <abstract><p>This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network.  ANDSF is being developed in the Third Generation Partnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes (MNs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-das-mipshop-andsf-dhcp-options-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6154</doc-id>
        <title>IMAP LIST Extension for Special-Use Mailboxes</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>J. Nicolson</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages.  Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes.  This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-morg-list-specialuse-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>morg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6154</errata-url>
        <doi>10.17487/RFC6154</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6155</doc-id>
        <title>Use of Device Identity in HTTP-Enabled Location Delivery (HELD)</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>R. Barnes</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
        </keywords>
        <abstract><p>When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.</p><p> Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.</p><p> This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-held-identity-extensions-06</draft>
        <updated-by>
            <doc-id>RFC6915</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6155</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6156</doc-id>
        <title>Traversal Using Relays around NAT (TURN) Extension for IPv6</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>O. Novo</name>
        </author>
        <author>
            <name>S. Perreault</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>STUN</kw>
            <kw>TURN</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document adds IPv6 support to Traversal Using Relays around NAT (TURN).  IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying.  This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN.  The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-turn-ipv6-11</draft>
        <obsoleted-by>
            <doc-id>RFC8656</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC6156</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6157</doc-id>
        <title>IPv6 Transition in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>K. El Malki</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up.  Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-v6-transition-07</draft>
        <updates>
            <doc-id>RFC3264</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6157</errata-url>
        <doi>10.17487/RFC6157</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6158</doc-id>
        <title>RADIUS Design Guidelines</title>
        <author>
            <name>A. DeKok</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Weber</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.  It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs).  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-radext-design-19</draft>
        <updated-by>
            <doc-id>RFC6929</doc-id>
            <doc-id>RFC8044</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0158</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC6158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6159</doc-id>
        <title>Session-Specific Explicit Diameter Request Routing</title>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Diameter routing</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-tsou-diameter-explicit-routing-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6160</doc-id>
        <title>Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type.  Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-cms-symmetrickeypackage-algs-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6160</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6161</doc-id>
        <title>Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>ecdsa</kw>
            <kw>ecdh</kw>
            <kw>EnvelopedData and Elliptic Curve Digital Signature Algorithm</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type.  Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData.  This document extends RFC 6033. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-ekpct-algs-update-03</draft>
        <updates>
            <doc-id>RFC6033</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6162</doc-id>
        <title>Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>ecdsa</kw>
            <kw>ecdh</kw>
            <kw>EnvelopedData and Elliptic Curve Digital Signature Algorithm</kw>
        </keywords>
        <abstract><p>This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type.  Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData.  This document extends RFC 5959. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-turner-akf-algs-update-03</draft>
        <updates>
            <doc-id>RFC5959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6162</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6163</doc-id>
        <title>Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Imajuku</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>Generalized Multi-Protocol Label Switching</kw>
            <kw>Routing and Wavelength Assignment</kw>
            <kw>RWA</kw>
        </keywords>
        <abstract><p>This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.</p><p> This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ccamp-rwa-wson-framework-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6163</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6164</doc-id>
        <title>Using 127-Bit IPv6 Prefixes on Inter-Router Links</title>
        <author>
            <name>M. Kohno</name>
        </author>
        <author>
            <name>B. Nitzan</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>Y. Matsuzaki</name>
        </author>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>addressing</kw>
            <kw>prefix length</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes.  Such a practice parallels the use of 31-bit prefixes in IPv4.  This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-prefixlen-p2p-01</draft>
        <updated-by>
            <doc-id>RFC6547</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6164</errata-url>
        <doi>10.17487/RFC6164</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6165</doc-id>
        <title>Extensions to IS-IS for Layer-2 Systems</title>
        <author>
            <name>A. Banerjee</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Intermediate System to Intermediate System</kw>
        </keywords>
        <abstract><p>This document specifies the Intermediate System to Intermediate System (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2.  While supporting this concept involves several pieces, this document only describes extensions to IS-IS.  Furthermore, the Type, Length, Value pairs (TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions.  We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. [STANDARDS- TRACK]</p></abstract>
        <draft>draft-ietf-isis-layer2-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC6165</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6166</doc-id>
        <title>A Registry for PIM Message Types</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>Protocol Independent Multicast</kw>
        </keywords>
        <abstract><p>This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types.</p><p> In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-registry-04</draft>
        <obsoleted-by>
            <doc-id>RFC8736</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6166</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6167</doc-id>
        <title>URI Scheme for Java(tm) Message Service 1.0</title>
        <author>
            <name>M. Phillips</name>
        </author>
        <author>
            <name>P. Adams</name>
        </author>
        <author>
            <name>D. Rokicki</name>
        </author>
        <author>
            <name>E. Johnson</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SOAP</kw>
            <kw>JMS</kw>
            <kw>JNDI</kw>
            <kw>IRI</kw>
        </keywords>
        <abstract><p>This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS).  It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination.  The syntax of this JMS URI is not compatible with previously existing, but unregistered, "jms" URI schemes.  However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-merrick-jms-uri-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6167</errata-url>
        <doi>10.17487/RFC6167</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6168</doc-id>
        <title>Requirements for Management of Name Servers for the DNS</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
            <kw>Management</kw>
        </keywords>
        <abstract><p>Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.</p><p> This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-dnsop-name-server-management-reqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC6168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6169</doc-id>
        <title>Security Concerns with IP Tunneling</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>J. Hoagland</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
        </keywords>
        <abstract><p>A number of security concerns with IP tunnels are documented in this memo.  The intended audience of this document includes network administrators and future protocol developers.  The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-v6ops-tunnel-security-concerns-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6169</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6170</doc-id>
        <title>Internet X.509 Public Key Infrastructure -- Certificate Image</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Bajaj</name>
        </author>
        <author>
            <name>L. Rosenthol</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>otherLogos</kw>
        </keywords>
        <abstract><p>This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-certimage-11</draft>
        <obsoleted-by>
            <doc-id>RFC9399</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3709</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC6170</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6171</doc-id>
        <title>The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>x.511</kw>
            <kw>dontusecopy</kw>
        </keywords>
        <abstract><p>This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service.  This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-zeilenga-ldap-dontusecopy-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6171</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6172</doc-id>
        <title>Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>D. Peterson</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>FCIP</kw>
        </keywords>
        <abstract><p>Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.</p><p> iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.</p><p> This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-storm-ifcp-ipn133-updates-03</draft>
        <updates>
            <doc-id>RFC4172</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC6172</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6173</doc-id>
        <title>Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)</title>
        <author>
            <name>P. Venkatesen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Management Information Base</kw>
            <kw>mib</kw>
            <kw>IFCP-MGMT-MIB</kw>
        </keywords>
        <abstract><p>This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.</p><p> This document obsoletes RFC 4369. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-storm-ifcpmib-07</draft>
        <obsoletes>
            <doc-id>RFC4369</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC6173</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6174</doc-id>
        <title>Definition of IETF Working Group Document States</title>
        <author>
            <name>E. Juskevicius</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>WG I-D States</kw>
            <kw>I-D Availability States</kw>
        </keywords>
        <abstract><p>The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.</p><p> This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-proto-wgdocument-states-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6174</errata-url>
        <doi>10.17487/RFC6174</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6175</doc-id>
        <title>Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors</title>
        <author>
            <name>E. Juskevicius</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>WG Document States</kw>
            <kw>I-D States</kw>
        </keywords>
        <abstract><p>This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs.  After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-juskevicius-datatracker-wgdocstate-reqts-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6175</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6176</doc-id>
        <title>Prohibiting Secure Sockets Layer (SSL) Version 2.0</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0.  This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-ssl2-must-not-04</draft>
        <updates>
            <doc-id>RFC2246</doc-id>
            <doc-id>RFC4346</doc-id>
            <doc-id>RFC5246</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6176</errata-url>
        <doi>10.17487/RFC6176</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6177</doc-id>
        <title>IPv6 Address Assignment to End Sites</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>L. Roberts</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>engineering steering group</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.</p><p> This document obsoletes RFC 3177. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-v6ops-3177bis-end-sites-01</draft>
        <obsoletes>
            <doc-id>RFC3177</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0157</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6177</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6178</doc-id>
        <title>Label Edge Router Forwarding of IPv4 Option Packets</title>
        <author>
            <name>D. Smith</name>
        </author>
        <author>
            <name>J. Mullooly</name>
        </author>
        <author>
            <name>W. Jaeger</name>
        </author>
        <author>
            <name>T. Scholl</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>MPLS</kw>
            <kw>LER</kw>
            <kw>Security</kw>
            <kw>DoS</kw>
        </keywords>
        <abstract><p>This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options.  Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC).  IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure.  Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments.  While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ip-options-07</draft>
        <updates>
            <doc-id>RFC3031</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6178</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6179</doc-id>
        <title>The Internet Routing Overlay Network (IRON)</title>
        <author>
            <name>F. Templin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Encapsulation</kw>
            <kw>Tunnel</kw>
            <kw>Architecture</kw>
            <kw>Scalability</kw>
            <kw>Mobility</kw>
            <kw>MANET</kw>
            <kw>Security</kw>
            <kw>Recursion</kw>
            <kw>Addressing</kw>
            <kw>Routing</kw>
            <kw>IPv6</kw>
            <kw>Aerospace</kw>
            <kw>Aeronautics</kw>
            <kw>Space</kw>
            <kw>IRON</kw>
            <kw>RANGER</kw>
            <kw>VET</kw>
            <kw>SEAL</kw>
            <kw>ISATAP</kw>
        </keywords>
        <abstract><p>Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated.  This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system.  IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal.  While business considerations are an important determining factor for widespread adoption, they are out of scope for this document.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-templin-iron-17</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6179</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6180</doc-id>
        <title>Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>The Internet continues to grow beyond the capabilities of IPv4.  An expansion in the address space is clearly required.  With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table.  Yet, IPv6 deployment requires some effort, resources, and expertise.  The availability of many different deployment models is one reason why expertise is required.  This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-arkko-ipv6-transition-guidelines-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6180</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6181</doc-id>
        <title>Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Multipath TCP</kw>
            <kw>threats</kw>
            <kw>security</kw>
            <kw>MPTCP</kw>
        </keywords>
        <abstract><p>Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data.  Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios.  Some level of multihoming and mobility support can be achieved through these extensions.  However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP.  This note includes a threat analysis for MPTCP.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mptcp-threat-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6181</errata-url>
        <doi>10.17487/RFC6181</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6182</doc-id>
        <title>Architectural Guidelines for Multipath TCP Development</title>
        <author>
            <name>A. Ford</name>
        </author>
        <author>
            <name>C. Raiciu</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>S. Barre</name>
        </author>
        <author>
            <name>J. Iyengar</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>multipath tcp architecture</kw>
        </keywords>
        <abstract><p>Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.</p><p> This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mptcp-architecture-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <doi>10.17487/RFC6182</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6183</doc-id>
        <title>IP Flow Information Export (IPFIX) Mediation: Framework</title>
        <author>
            <name>A. Kobayashi</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>G. Muenz</name>
        </author>
        <author>
            <name>K. Ishibashi</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document describes a framework for IP Flow Information Export (IPFIX) Mediation.  This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ipfix-mediators-framework-09</draft>
        <updates>
            <doc-id>RFC5470</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6183</errata-url>
        <doi>10.17487/RFC6183</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6184</doc-id>
        <title>RTP Payload Format for H.264 Video</title>
        <author>
            <name>Y.-K. Wang</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>T. Kristensen</name>
        </author>
        <author>
            <name>R. Jesup</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>AVC</kw>
            <kw>H.264/AVC</kw>
            <kw>Advanced Video Coding</kw>
        </keywords>
        <abstract><p>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, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. 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 bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.</p><p> This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-rfc3984bis-12</draft>
        <obsoletes>
            <doc-id>RFC3984</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6184</errata-url>
        <doi>10.17487/RFC6184</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6185</doc-id>
        <title>RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video</title>
        <author>
            <name>T. Kristensen</name>
        </author>
        <author>
            <name>P. Luthi</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>H.264</kw>
            <kw>H.241</kw>
            <kw>ITU-T</kw>
            <kw>RTP</kw>
            <kw>Video</kw>
            <kw>SDP</kw>
            <kw>RCDO</kw>
        </keywords>
        <abstract><p>This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241.  RCDO reduces the decoding cost and resource consumption of the video processing.  The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-h264-rcdo-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC6185</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6186</doc-id>
        <title>Use of SRV Records for Locating Email Submission/Access Services</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>imap</kw>
            <kw>pop3</kw>
            <kw>smtp</kw>
            <kw>dns</kw>
            <kw>discovery</kw>
        </keywords>
        <abstract><p>This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-daboo-srv-email-05</draft>
        <updates>
            <doc-id>RFC1939</doc-id>
            <doc-id>RFC3501</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8314</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6186</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6187</doc-id>
        <title>X.509v3 Certificates for Secure Shell Authentication</title>
        <author>
            <name>K. Igoe</name>
        </author>
        <author>
            <name>D. Stebila</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
        </keywords>
        <abstract><p>X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity.  This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-igoe-secsh-x509v3-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6187</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6188</doc-id>
        <title>The Use of AES-192 and AES-256 in Secure RTP</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SRTP</kw>
        </keywords>
        <abstract><p>This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol.  It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-srtp-big-aes-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6188</errata-url>
        <doi>10.17487/RFC6188</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6189</doc-id>
        <title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title>
        <author>
            <name>P. Zimmermann</name>
        </author>
        <author>
            <name>A. Johnston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Callas</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>115</page-count>
        <abstract><p>This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications.  The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol.  ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices.  For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication.  ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel.  To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles.  ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-zimmermann-avt-zrtp-22</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6189</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6190</doc-id>
        <title>RTP Payload Format for Scalable Video Coding</title>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>Y.-K. Wang</name>
        </author>
        <author>
            <name>T. Schierl</name>
        </author>
        <author>
            <name>A. Eleftheriadis</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>SVC</kw>
            <kw>AVC</kw>
            <kw>H.264/AVC</kw>
            <kw>Advanced Video Coding</kw>
            <kw>Scalable Video Coding</kw>
        </keywords>
        <abstract><p>This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10.  The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets.  Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions.  The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184.  The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-svc-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6190</errata-url>
        <doi>10.17487/RFC6190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6191</doc-id>
        <title>Reducing the TIME-WAIT State Using TCP Timestamps</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment.  This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-timestamps-04</draft>
        <is-also>
            <doc-id>BCP0159</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6191</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6192</doc-id>
        <title>Protecting the Router Control Plane</title>
        <author>
            <name>D. Dugal</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>R. Dunn</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ACL</kw>
            <kw>Router Control Plane Protection</kw>
            <kw>Filter</kw>
        </keywords>
        <abstract><p>This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.</p><p> Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-opsec-protect-control-plane-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6192</errata-url>
        <doi>10.17487/RFC6192</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6193</doc-id>
        <title>Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)</title>
        <author>
            <name>M. Saito</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>M. Toyama</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>IPsec</kw>
            <kw>setup</kw>
            <kw>VPN</kw>
        </keywords>
        <abstract><p>This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers.  It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model.  It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-saito-mmusic-sdp-ike-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6193</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6194</doc-id>
        <title>Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms</title>
        <author>
            <name>T. Polk</name>
        </author>
        <author>
            <name>L. Chen</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-sha0-sha1-seccon-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6194</errata-url>
        <doi>10.17487/RFC6194</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6195</doc-id>
        <title>Domain Name System (DNS) IANA Considerations</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RRTYPE</kw>
            <kw>RCODE</kw>
            <kw>AFSDB</kw>
        </keywords>
        <abstract><p>This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-dnsext-5395bis-03</draft>
        <obsoletes>
            <doc-id>RFC5395</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC6895</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1183</doc-id>
            <doc-id>RFC3597</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6195</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6196</doc-id>
        <title>Moving mailserver: URI Scheme to Historic</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>mailserver</kw>
            <kw>URI</kw>
        </keywords>
        <abstract><p>This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-mailserver-uri-to-historic-00</draft>
        <updates>
            <doc-id>RFC1738</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6196</errata-url>
        <doi>10.17487/RFC6196</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6197</doc-id>
        <title>Location-to-Service Translation (LoST) Service List Boundary Extension</title>
        <author>
            <name>K. Wolf</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>listservicesbylocation</kw>
        </keywords>
        <abstract><p>Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs.  If a LoST client wants to discover available services for a particular location, it will perform a &lt;listServicesByLocation&gt; query to the LoST server.  However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid.  Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ecrit-lost-servicelistboundary-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC6197</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6198</doc-id>
        <title>Requirements for the Graceful Shutdown of BGP Sessions</title>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>P. Francois</name>
        </author>
        <author>
            <name>C. Pelsser</name>
        </author>
        <author>
            <name>Z. Ahmad</name>
        </author>
        <author>
            <name>A.J. Elizondo Armengol</name>
        </author>
        <author>
            <name>T. Takeda</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>BGP</kw>
            <kw>graceful</kw>
            <kw>shutdown</kw>
            <kw>connectivity loss</kw>
            <kw>maintenance</kw>
            <kw>network operation</kw>
            <kw>make-before-break</kw>
            <kw>planned</kw>
        </keywords>
        <abstract><p>The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services.  For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic.  However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence.  This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN).  Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown.  This document expresses requirements for such a solution.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-grow-bgp-graceful-shutdown-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6198</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6199</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6200</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6201</doc-id>
        <title>Device Reset Characterization</title>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>F. Calabria</name>
        </author>
        <author>
            <name>C. Olvera</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>operation redundancy failover</kw>
        </keywords>
        <abstract><p>An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.</p><p> This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-bmwg-reset-06</draft>
        <updates>
            <doc-id>RFC1242</doc-id>
            <doc-id>RFC2544</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6201</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6202</doc-id>
        <title>Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP</title>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>S. Salsano</name>
        </author>
        <author>
            <name>G. Wilkins</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>bidirectional HTTP</kw>
            <kw>HTTP long polling</kw>
            <kw>HTTP streaming</kw>
        </keywords>
        <abstract><p>On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server.  This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-loreto-http-bidirectional-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6202</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6203</doc-id>
        <title>IMAP4 Extension for Fuzzy Search</title>
        <author>
            <name>T. Sirainen</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>email</kw>
        </keywords>
        <abstract><p>This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-morg-fuzzy-search-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>morg</wg_acronym>
        <doi>10.17487/RFC6203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6204</doc-id>
        <title>Basic Requirements for IPv6 Customer Edge Routers</title>
        <author>
            <name>H. Singh</name>
        </author>
        <author>
            <name>W. Beebee</name>
        </author>
        <author>
            <name>C. Donley</name>
        </author>
        <author>
            <name>B. Stark</name>
        </author>
        <author>
            <name>O. Troan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPv6 CE requirements</kw>
        </keywords>
        <abstract><p>This document specifies requirements for an IPv6 Customer Edge (CE) router.  Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-cpe-router-09</draft>
        <obsoleted-by>
            <doc-id>RFC7084</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6204</errata-url>
        <doi>10.17487/RFC6204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6205</doc-id>
        <title>Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers</title>
        <author>
            <name>T. Otani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>DWDM</kw>
            <kw>CWDM</kw>
            <kw>Wavelength Label</kw>
            <kw>LSC</kw>
        </keywords>
        <abstract><p>Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.</p><p> Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered.</p><p> In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-g-694-lambda-labels-11</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7699</doc-id>
            <doc-id>RFC8359</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6206</doc-id>
        <title>The Trickle Algorithm</title>
        <author>
            <name>P. Levis</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>O. Gnawali</name>
        </author>
        <author>
            <name>J. Ko</name>
        </author>
        <date>
            <month>March</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Consistency</kw>
            <kw>Eventual consistency</kw>
            <kw>Low-power</kw>
            <kw>Low power</kw>
        </keywords>
        <abstract><p>The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner.  Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change.  A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density.  This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-roll-trickle-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC6206</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6207</doc-id>
        <title>The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml</title>
        <author>
            <name>R. Denenberg</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>mods</kw>
            <kw>Metadata Object Description Schema</kw>
            <kw>MADS</kw>
            <kw>Metadata Authority Description Schema</kw>
            <kw>METS</kw>
            <kw>Metadata Encoding and Transmission Standard</kw>
            <kw>MARCXML</kw>
            <kw>MARC21 XML Schema</kw>
            <kw>SRU</kw>
            <kw>Search/Retrieve via URL Response Format</kw>
        </keywords>
        <abstract><p>This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema.  These are all XML schemas providing representations of various forms of information including metadata and search results.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-denenberg-mods-etc-media-types-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6208</doc-id>
        <title>Cloud Data Management Interface (CDMI) Media Types</title>
        <author>
            <name>K. Sankar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Jones</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>snia</kw>
            <kw>Storage Networking Industry Association</kw>
        </keywords>
        <abstract><p>This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:</p><p> o application/cdmi-object</p><p> o application/cdmi-container</p><p> o application/cdmi-domain</p><p> o application/cdmi-capability</p><p> o application/cdmi-queue</p><p> This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-cdmi-mediatypes-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6209</doc-id>
        <title>Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)</title>
        <author>
            <name>W. Kim</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>J. Park</name>
        </author>
        <author>
            <name>D. Kwon</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>aria encryption</kw>
        </keywords>
        <abstract><p>This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-nsri-tls-aria-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6209</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6210</doc-id>
        <title>Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>example</kw>
            <kw>MD5-XOR</kw>
            <kw>Parameterized</kw>
        </keywords>
        <abstract><p>New hash algorithms are being developed that may include parameters.  Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems.  This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-schaad-smime-hash-experiment-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6210</errata-url>
        <doi>10.17487/RFC6210</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6211</doc-id>
        <title>Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>example</kw>
            <kw>s/mime</kw>
            <kw>SMIME</kw>
        </keywords>
        <abstract><p>The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks.  In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process.  In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process.  This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-schaad-smime-algorithm-attribute-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6211</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6212</doc-id>
        <title>Authentication-Results Registration for Vouch by Reference Results</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>VBR</kw>
            <kw>Reputation</kw>
            <kw>DKIM</kw>
        </keywords>
        <abstract><p>This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kucherawy-authres-vbr-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6212</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6213</doc-id>
        <title>IS-IS BFD-Enabled TLV</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>type-length-value</kw>
            <kw>Bidirectional Forwarding Detection</kw>
        </keywords>
        <abstract><p>This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol.  There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-bfd-tlv-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC6213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6214</doc-id>
        <title>Adaptation of RFC 1149 for IPv6</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>avian carrier</kw>
            <kw>april fool</kw>
        </keywords>
        <abstract><p>This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-carpenter-6man-adapt-rfc1149-00</draft>
        <updates>
            <doc-id>RFC1149</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6214</errata-url>
        <doi>10.17487/RFC6214</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6215</doc-id>
        <title>MPLS Transport Profile User-to-Network and Network-to-Network Interfaces</title>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>L. Levrau</name>
        </author>
        <author>
            <name>D. Frost</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-uni-nni-03</draft>
        <updates>
            <doc-id>RFC5921</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6215</errata-url>
        <doi>10.17487/RFC6215</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6216</doc-id>
        <title>Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>K. Ono</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>B. Hibbard</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <abstract><p>This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP).  It also provides information that helps implementers build interoperable SIP software.  To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipcore-sec-flows-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC6216</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6217</doc-id>
        <title>Regional Broadcast Using an Atmospheric Link Layer</title>
        <author>
            <name>T. Ritter</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Broadcasting is a technology that has been largely discarded in favor of technologies like multicast.  This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer.  It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ritter-regional-bcast-atmospheric-linklayer-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6217</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6218</doc-id>
        <title>Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>T. Zhang</name>
        </author>
        <author>
            <name>J. Walker</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.  These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-zorn-radius-keywrap-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6218</errata-url>
        <doi>10.17487/RFC6218</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6219</doc-id>
        <title>The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition</title>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>H. Zhang</name>
        </author>
        <author>
            <name>J. Wu</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Stateless IPv4/IPv6 translation</kw>
            <kw>IPv4/IPv6 Header Translation</kw>
            <kw>IPv4-embedded IPv6 Address</kw>
            <kw>IPv4/IPv6 Multicast Translation</kw>
            <kw>stateless NAT64</kw>
        </keywords>
        <abstract><p>This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.</p><p> The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-xli-behave-ivi-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6219</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6220</doc-id>
        <title>Defining the Role and Function of IETF Protocol Parameter Registry Operators</title>
        <author>
            <name>D. McPherson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Klensin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Huston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets.  To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined.  The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions.  For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity.  This document provides a description of, and the requirements for, these delegated functions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-iana-08</draft>
        <obsoleted-by>
            <doc-id>RFC8722</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6220</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6221</doc-id>
        <title>Lightweight DHCPv6 Relay Agent</title>
        <author>
            <name>D. Miles</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Ooghe</name>
        </author>
        <author>
            <name>W. Dec</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>A. Kavanagh</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>dsl</kw>
        </keywords>
        <abstract><p>This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces.  The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-ldra-03</draft>
        <updates>
            <doc-id>RFC3315</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6221</errata-url>
        <doi>10.17487/RFC6221</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6222</doc-id>
        <title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint.  While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.  For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session.  However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness.  This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-cnames-05</draft>
        <obsoleted-by>
            <doc-id>RFC7022</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3550</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC6222</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6223</doc-id>
        <title>Indication of Support for Keep-Alive</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>STUN</kw>
            <kw>outbound</kw>
            <kw>NAT traversal</kw>
        </keywords>
        <abstract><p>This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-keep-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC6223</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6224</doc-id>
        <title>Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains</title>
        <author>
            <name>T. Schmidt</name>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MLD proxy</kw>
            <kw>multicast routing</kw>
            <kw>mobility management</kw>
            <kw>transparent handover</kw>
        </keywords>
        <abstract><p>This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards.  Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions.  In this scenario, mobile nodes remain agnostic of multicast mobility operations.  Support for mobile multicast senders is outside the scope of this document.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-multimob-pmipv6-base-solution-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>multimob</wg_acronym>
        <doi>10.17487/RFC6224</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6225</doc-id>
        <title>Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information</title>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>M. Linsner</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client.  The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each.  Separate parameters indicate the reference datum for each of these values.  This document obsoletes RFC 3825. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-rfc3825bis-17</draft>
        <obsoletes>
            <doc-id>RFC3825</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6225</errata-url>
        <doi>10.17487/RFC6225</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6226</doc-id>
        <title>PIM Group-to-Rendezvous-Point Mapping</title>
        <author>
            <name>B. Joshi</name>
        </author>
        <author>
            <name>A. Kessler</name>
        </author>
        <author>
            <name>D. McWalter</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>auto-RP BSR hash</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract><p>Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.</p><p> This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-group-rp-mapping-10</draft>
        <updates>
            <doc-id>RFC4601</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6226</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6227</doc-id>
        <title>Design Goals for Scalable Internet Routing</title>
        <author>
            <name>T. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>routing  architecture</kw>
            <kw>addressing architecture</kw>
        </keywords>
        <abstract><p>It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering.  The Routing Research Group is investigating an alternate architecture to meet these challenges.  This document consists of a prioritized list of design goals for the target architecture.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-rrg-design-goals-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6228</doc-id>
        <title>Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>199</kw>
            <kw>Early dialog</kw>
            <kw>Forking</kw>
            <kw>Provisional response</kw>
        </keywords>
        <abstract><p>This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-199-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6228</errata-url>
        <doi>10.17487/RFC6228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6229</doc-id>
        <title>Test Vectors for the Stream Cipher RC4</title>
        <author>
            <name>J. Strombergson</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>arcfour128</kw>
            <kw>arcfour256</kw>
            <kw>arcfour</kw>
            <kw>ARC4m</kw>
            <kw>Stream Cipher</kw>
            <kw>Test Vectors</kw>
            <kw>Known Answer Test</kw>
            <kw>arcfour</kw>
            <kw>ARC4</kw>
            <kw>WEP</kw>
            <kw>WPA</kw>
            <kw>RFC 4345</kw>
        </keywords>
        <abstract><p>This document contains test vectors for the stream cipher RC4.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-josefsson-rc4-test-vectors-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6229</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6230</doc-id>
        <title>Media Control Channel Framework</title>
        <author>
            <name>C. Boulton</name>
        </author>
        <author>
            <name>T. Melanchuk</name>
        </author>
        <author>
            <name>S. McGlashan</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.</p><p> The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mediactrl-sip-control-framework-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6230</errata-url>
        <doi>10.17487/RFC6230</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6231</doc-id>
        <title>An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework</title>
        <author>
            <name>S. McGlashan</name>
        </author>
        <author>
            <name>T. Melanchuk</name>
        </author>
        <author>
            <name>C. Boulton</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>134</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences.  The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications.  Dialog interactions are specified in a dialog language.  This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used.  The package also defines elements for auditing package capabilities and IVR dialogs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mediactrl-ivr-control-package-11</draft>
        <updated-by>
            <doc-id>RFC6623</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6231</errata-url>
        <doi>10.17487/RFC6231</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6232</doc-id>
        <title>Purge Originator Identification TLV for IS-IS</title>
        <author>
            <name>F. Wei</name>
        </author>
        <author>
            <name>Y. Qin</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Purge Originator Identification</kw>
            <kw>IIH:n</kw>
            <kw>LSP:y</kw>
            <kw>SNP:n</kw>
            <kw>Purge:y</kw>
        </keywords>
        <abstract><p>At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS.</p><p> To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.</p><p> This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-purge-tlv-05</draft>
        <updates>
            <doc-id>RFC5301</doc-id>
            <doc-id>RFC5304</doc-id>
            <doc-id>RFC5310</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8918</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC6232</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6233</doc-id>
        <title>IS-IS Registry Extension for Purges</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Intermediate System to Intermediate System</kw>
            <kw>LSP</kw>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>IANA maintains the "IS-IS TLV Codepoints" registry.  This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a.  purges.  This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication.  This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-reg-purge-01</draft>
        <updates>
            <doc-id>RFC3563</doc-id>
            <doc-id>RFC5304</doc-id>
            <doc-id>RFC5310</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC6233</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6234</doc-id>
        <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>127</page-count>
        <abstract><p>Federal Information Processing Standard, FIPS</p></abstract>
        <draft>draft-eastlake-sha2b-07</draft>
        <obsoletes>
            <doc-id>RFC4634</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3174</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6234</errata-url>
        <doi>10.17487/RFC6234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6235</doc-id>
        <title>IP Flow Anonymization Support</title>
        <author>
            <name>E. Boschi</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>flow information export</kw>
            <kw>address anonymization</kw>
            <kw>pseudonymization</kw>
            <kw>data protection</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol.  It categorizes common anonymization schemes and defines the parameters needed to describe them.  It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ipfix-anon-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6235</errata-url>
        <doi>10.17487/RFC6235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6236</doc-id>
        <title>Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)</title>
        <author>
            <name>I. Johansson</name>
        </author>
        <author>
            <name>K. Jung</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size.  A possible use case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power.  The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-image-attributes-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6236</errata-url>
        <doi>10.17487/RFC6236</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6237</doc-id>
        <title>IMAP4 Multimailbox SEARCH Extension</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>email</kw>
            <kw>multiple mailboxes</kw>
            <kw>imapext</kw>
        </keywords>
        <abstract><p>The IMAP4 specification allows the searching of only the selected mailbox.  A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next.  This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox.  This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses.  This document updates RFC 4466.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-morg-multimailbox-search-07</draft>
        <obsoleted-by>
            <doc-id>RFC7377</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4466</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>morg</wg_acronym>
        <doi>10.17487/RFC6237</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6238</doc-id>
        <title>TOTP: Time-Based One-Time Password Algorithm</title>
        <author>
            <name>D. M'Raihi</name>
        </author>
        <author>
            <name>S. Machani</name>
        </author>
        <author>
            <name>M. Pei</name>
        </author>
        <author>
            <name>J. Rydell</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>OTP</kw>
            <kw>OATH</kw>
            <kw>HOTP</kw>
            <kw>two factor authentication</kw>
            <kw>strong authentication</kw>
        </keywords>
        <abstract><p>This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.</p><p> The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mraihi-totp-timebased-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6238</errata-url>
        <doi>10.17487/RFC6238</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6239</doc-id>
        <title>Suite B Cryptographic Suites for Secure Shell (SSH)</title>
        <author>
            <name>K. Igoe</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol.  Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-igoe-secsh-suiteb-06</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6239</errata-url>
        <doi>10.17487/RFC6239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6240</doc-id>
        <title>Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2</title>
        <author>
            <name>D. Zelig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Cohen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>PW-CEP-STD-MIB</kw>
        </keywords>
        <abstract><p>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 modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-cep-mib-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6240</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6241</doc-id>
        <title>Network Configuration Protocol (NETCONF)</title>
        <author>
            <name>R. Enns</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Bjorklund</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Bierman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>113</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>Configuration</kw>
            <kw>Network Management</kw>
            <kw>Extensible Markup Language</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-4741bis-10</draft>
        <obsoletes>
            <doc-id>RFC4741</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7803</doc-id>
            <doc-id>RFC8526</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6241</errata-url>
        <doi>10.17487/RFC6241</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6242</doc-id>
        <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
        <author>
            <name>M. Wasserman</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>network configuration protocol</kw>
        </keywords>
        <abstract><p>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-rfc4742bis-08</draft>
        <obsoletes>
            <doc-id>RFC4742</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6242</errata-url>
        <doi>10.17487/RFC6242</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6243</doc-id>
        <title>With-defaults Capability for NETCONF</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>B. Lengyel</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>network configuration protocol</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server.  In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead.  In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply.  In other situations the NETCONF client will need this data from the server.  Not all server implementations treat this default data the same way.  This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-with-defaults-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6243</errata-url>
        <doi>10.17487/RFC6243</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6244</doc-id>
        <title>An Architecture for Network Management Using NETCONF and YANG</title>
        <author>
            <name>P. Shafer</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>network configuration protocol</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.</p><p> This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-netmod-arch-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6244</errata-url>
        <doi>10.17487/RFC6244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6245</doc-id>
        <title>Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4</title>
        <author>
            <name>P. Yegani</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>J. Navali</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream.  This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field.  This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic.  The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4.  GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses.  When the tuple &lt;Care of Address, Home Address, and Home Agent Address&gt; is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key.  In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-gre-key-extension-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC6245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6246</doc-id>
        <title>Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Brockners</name>
        </author>
        <author>
            <name>D. Mohan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Serbest</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ieee bridges</kw>
        </keywords>
        <abstract><p>One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.</p><p> When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-bridge-interop-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC6246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6247</doc-id>
        <title>Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document reclassifies several TCP extensions that have never seen widespread use to Historic status.  The affected RFCs are RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-eggert-tcpm-historicize-02</draft>
        <obsoletes>
            <doc-id>RFC1072</doc-id>
            <doc-id>RFC1106</doc-id>
            <doc-id>RFC1110</doc-id>
            <doc-id>RFC1145</doc-id>
            <doc-id>RFC1146</doc-id>
            <doc-id>RFC1379</doc-id>
            <doc-id>RFC1644</doc-id>
            <doc-id>RFC1693</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4614</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6247</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6248</doc-id>
        <title>RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete.  The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics.  Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-morton-ippm-rfc4148-obsolete-03</draft>
        <obsoletes>
            <doc-id>RFC4148</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4737</doc-id>
            <doc-id>RFC5560</doc-id>
            <doc-id>RFC5644</doc-id>
            <doc-id>RFC6049</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6248</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6249</doc-id>
        <title>Metalink/HTTP: Mirrors and Hashes</title>
        <author>
            <name>A. Bryan</name>
        </author>
        <author>
            <name>N. McNab</name>
        </author>
        <author>
            <name>T. Tsujikawa</name>
        </author>
        <author>
            <name>P. Poeml</name>
        </author>
        <author>
            <name>H. Nordstrom</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>file transfer</kw>
            <kw>download</kw>
            <kw>link</kw>
            <kw>signature</kw>
            <kw>data integrity</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>ftp</kw>
            <kw>file transfer protocol</kw>
            <kw>metadata</kw>
            <kw>torrent</kw>
        </keywords>
        <abstract><p>This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format.  Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields.  Metalink clients can use this information to make file transfers more robust and reliable.  Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-bryan-metalinkhttp-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6249</errata-url>
        <doi>10.17487/RFC6249</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6250</doc-id>
        <title>Evolution of the IP Model</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>service model</kw>
        </keywords>
        <abstract><p>This RFC attempts to document various aspects of the IP service model and how it has evolved over time.  In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed.  The discussion of these properties is organized around evaluating a set of claims, or misconceptions.  Finally, this document provides some guidance to protocol designers and implementers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-ip-model-evolution-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6251</doc-id>
        <title>Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>kerberos</kw>
            <kw>tls</kw>
            <kw>starttls</kw>
            <kw>kdc</kw>
        </keywords>
        <abstract><p>This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-josefsson-kerberos5-starttls-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6252</doc-id>
        <title>A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization</title>
        <author>
            <name>A. Dutta</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Fajardo</name>
        </author>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>K. Taniuchi</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>Mobility</kw>
            <kw>Optimization</kw>
            <kw>Proactive handoff</kw>
            <kw>Link-layer security</kw>
            <kw>Handover taxonomy</kw>
            <kw>Layer 2 handoff</kw>
            <kw>Layer 3 handoff</kw>
            <kw>Network discovery</kw>
            <kw>Handover delay</kw>
            <kw>Packet loss</kw>
            <kw>Proactive binding update</kw>
            <kw>Multi-interface</kw>
            <kw>IP address acquisition</kw>
            <kw>Tunnel management</kw>
        </keywords>
        <abstract><p>This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.</p><p> This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-mobopts-mpa-framework-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6252</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6253</doc-id>
        <title>Host Identity Protocol Certificates</title>
        <author>
            <name>T. Heer</name>
        </author>
        <author>
            <name>S. Varjonen</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates.</p><p> The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.</p><p> This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-cert-12</draft>
        <obsoleted-by>
            <doc-id>RFC8002</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5201</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC6253</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6254</doc-id>
        <title>Request to Move RFC 2754 to Historic Status</title>
        <author>
            <name>M. McFadden</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>RPS</kw>
        </keywords>
        <abstract><p>RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them.  The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System.  In practice, this was never done on the public Internet.  This document requests that RFC 2754 be moved to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iana-rfc2754-to-historic-02</draft>
        <obsoletes>
            <doc-id>RFC2754</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6254</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6255</doc-id>
        <title>Delay-Tolerant Networking Bundle Protocol IANA Registries</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>SNDV</kw>
            <kw>DTNRG</kw>
            <kw>Space networking</kw>
        </keywords>
        <abstract><p>The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol.  The specifications of these protocols contain fields that are subject to a registry.  For the purpose of its research work, the group created ad hoc registries.  As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody.  This document describes the actions executed by IANA.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-dtnrg-iana-bp-registries-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6256</doc-id>
        <title>Using Self-Delimiting Numeric Values in Protocols</title>
        <author>
            <name>W. Eddy</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SDNV</kw>
            <kw>DTN</kw>
        </keywords>
        <abstract><p>Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols.  SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead.  They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development.  This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage.  This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-dtnrg-sdnv-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6256</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6257</doc-id>
        <title>Bundle Security Protocol Specification</title>
        <author>
            <name>S. Symington</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>H. Weiss</name>
        </author>
        <author>
            <name>P. Lovell</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <abstract><p>This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.</p><p> This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-bundle-security-19</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6257</errata-url>
        <doi>10.17487/RFC6257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6258</doc-id>
        <title>Delay-Tolerant Networking Metadata Extension Block</title>
        <author>
            <name>S. Symington</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>Delay-Tolerant Networking</kw>
            <kw>Distruption-Tolerant Networking</kw>
        </keywords>
        <abstract><p>This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol.  This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle.  The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field.  One specific metadata type, for carrying URIs as metadata, is defined in this document.  Other metadata types may be defined in separate documents.  This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-bundle-metadata-block-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6258</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6259</doc-id>
        <title>Delay-Tolerant Networking Previous-Hop Insertion Block</title>
        <author>
            <name>S. Symington</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>Delay-Tolerant Networking</kw>
            <kw>Distruption-Tolerant Networking</kw>
        </keywords>
        <abstract><p>This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol.  This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node.  Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing).  If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle.  Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop.  This document defines the format and processing of this PHIB.  This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-bundle-previous-hop-block-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6259</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6260</doc-id>
        <title>Compressed Bundle Header Encoding (CBHE)</title>
        <author>
            <name>S. Burleigh</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>delay-tolerant networking</kw>
            <kw>BP</kw>
            <kw>bundle protocol</kw>
            <kw>IPN</kw>
        </keywords>
        <abstract><p>This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.</p><p> Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.</p><p> This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-cbhe-09</draft>
        <updated-by>
            <doc-id>RFC9758</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6260</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6261</doc-id>
        <title>Encrypted Signaling Transport Modes for the Host Identity Protocol</title>
        <author>
            <name>A. Keranen</name>
        </author>
        <date>
            <month>May</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-over-hip-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC6261</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6262</doc-id>
        <title>RTP Payload Format for IP-MR Speech Codec</title>
        <author>
            <name>S. Ikonin</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ipmr</kw>
            <kw>vocoder</kw>
            <kw>multirate</kw>
            <kw>scalable</kw>
            <kw>scalability</kw>
        </keywords>
        <abstract><p>This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP).  The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rtp-ipmr-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC6262</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6263</doc-id>
        <title>Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows</title>
        <author>
            <name>X. Marjou</name>
        </author>
        <author>
            <name>A. Sollaud</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>AVT</kw>
            <kw>SDP</kw>
            <kw>port</kw>
        </keywords>
        <abstract><p>This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive.  It also makes a recommendation for a preferred mechanism.  This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-app-rtp-keepalive-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6263</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6264</doc-id>
        <title>An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition</title>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>D. Guo</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.</p><p> This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-incremental-cgn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6265</doc-id>
        <title>HTTP State Management Mechanism</title>
        <author>
            <name>A. Barth</name>
        </author>
        <date>
            <month>April</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Cookie</kw>
            <kw>Set-Cookie</kw>
            <kw>Secure</kw>
            <kw>HttpOnly</kw>
        </keywords>
        <abstract><p>This document defines the HTTP Cookie and Set-Cookie header fields.  These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-httpstate-cookie-23</draft>
        <obsoletes>
            <doc-id>RFC2965</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>httpstate</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6265</errata-url>
        <doi>10.17487/RFC6265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6266</doc-id>
        <title>Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>filename</kw>
            <kw>attachment</kw>
            <kw>inline</kw>
        </keywords>
        <abstract><p>RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard.  This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-httpbis-content-disp-09</draft>
        <updates>
            <doc-id>RFC2616</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6266</errata-url>
        <doi>10.17487/RFC6266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6267</doc-id>
        <title>MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>V. Cakulev</name>
        </author>
        <author>
            <name>G. Sundaram</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Identity based encryption</kw>
            <kw>authentication</kw>
            <kw>key agreement</kw>
        </keywords>
        <abstract><p>This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service.  In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework.  This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-cakulev-mikey-ibake-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6268</doc-id>
        <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>ASN.1</kw>
            <kw>Certficate Extensions</kw>
            <kw>HMAC</kw>
        </keywords>
        <abstract><p>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version.  There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-additional-new-asn-08</draft>
        <updates>
            <doc-id>RFC5911</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6268</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6269</doc-id>
        <title>Issues with IP Address Sharing</title>
        <author>
            <name>M. Ford</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>P. Levis</name>
        </author>
        <author>
            <name>P. Roberts</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>IPv4 address exhaustion</kw>
            <kw>completion</kw>
            <kw>shared</kw>
            <kw>sharing issues</kw>
        </keywords>
        <abstract><p>The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.</p><p> Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-intarea-shared-addressing-issues-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC6269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6270</doc-id>
        <title>The 'tn3270' URI Scheme</title>
        <author>
            <name>M. Yevstifeyev</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>URI</kw>
            <kw>Telnet</kw>
            <kw>Telnet 3270</kw>
            <kw>TN3270</kw>
        </keywords>
        <abstract><p>This document is the specification of the 'tn3270' Uniform Resource Identifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270 Enhanced mode (TN3270E).  It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned this URI scheme without defining its syntax and semantics. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-yevstifeyev-tn3270-uri-18</draft>
        <updates>
            <doc-id>RFC2355</doc-id>
            <doc-id>RFC1738</doc-id>
            <doc-id>RFC1041</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6270</errata-url>
        <doi>10.17487/RFC6270</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6271</doc-id>
        <title>Requirements for SIP-Based Session Peering</title>
        <author>
            <name>J-F. Mule</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IETF speermint</kw>
            <kw>guidelines</kw>
            <kw>requirements for session interconnects</kw>
            <kw>session peering</kw>
            <kw>SIP interconnects</kw>
            <kw>VoIP peering</kw>
        </keywords>
        <abstract><p>This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic.  This informational document is intended to link the various use cases described for session peering to protocol solutions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-speermint-requirements-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speermint</wg_acronym>
        <doi>10.17487/RFC6271</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6272</doc-id>
        <title>Internet Protocols for the Smart Grid</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <abstract><p>This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid.  The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid.  In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-baker-ietf-core-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6272</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6273</doc-id>
        <title>The Secure Neighbor Discovery (SEND) Hash Threat Analysis</title>
        <author>
            <name>A. Kukec</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND.  The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility.  This document provides an analysis of possible threats to the hash algorithms used in SEND.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-csi-hash-threat-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>csi</wg_acronym>
        <doi>10.17487/RFC6273</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6274</doc-id>
        <title>Security Assessment of the Internet Protocol Version 4</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>vulnerabilities</kw>
            <kw>Denial of Service</kw>
            <kw>resiliency</kw>
            <kw>hardening</kw>
            <kw>information leakage</kw>
        </keywords>
        <abstract><p>This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations.  It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-opsec-ip-security-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6274</errata-url>
        <doi>10.17487/RFC6274</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6275</doc-id>
        <title>Mobility Support in IPv6</title>
        <author>
            <name>C. Perkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Johnson</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>169</page-count>
        <keywords>
            <kw>MIPv6</kw>
            <kw>mobility</kw>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
            <kw>nodes</kw>
        </keywords>
        <abstract><p>This document specifies Mobile IPv6, a protocol that 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.  This document obsoletes RFC 3775. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mext-rfc3775bis-13</draft>
        <obsoletes>
            <doc-id>RFC3775</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6275</errata-url>
        <doi>10.17487/RFC6275</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6276</doc-id>
        <title>DHCPv6 Prefix Delegation for Network Mobility (NEMO)</title>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <author>
            <name>W. Haddad</name>
        </author>
        <author>
            <name>C. Bernardos</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>mobile router</kw>
            <kw>home agent</kw>
            <kw>mobile network prefix</kw>
        </keywords>
        <abstract><p>One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network.  This document specifies how DHCPv6 prefix delegation can be used for this configuration task.  The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router.  When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mext-nemo-pd-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6276</errata-url>
        <doi>10.17487/RFC6276</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6277</doc-id>
        <title>Online Certificate Status Protocol Algorithm Agility</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ocsp</kw>
        </keywords>
        <abstract><p>The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used.  This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use.  This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-ocspagility-10</draft>
        <obsoleted-by>
            <doc-id>RFC6960</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2560</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6277</errata-url>
        <doi>10.17487/RFC6277</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6278</doc-id>
        <title>Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax</title>
        <author>
            <name>J. Herzog</name>
        </author>
        <author>
            <name>R. Khazan</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>set-key</kw>
            <kw>group-key</kw>
        </keywords>
        <abstract><p>This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax.  In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-herzog-static-ecdh-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6278</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6279</doc-id>
        <title>Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement</title>
        <author>
            <name>M. Liebsch</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Jeong</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Local Routing</kw>
            <kw>Route Optimization</kw>
            <kw>Traffic Offload</kw>
        </keywords>
        <abstract><p>Proxy Mobile IPv6 is the IETF Standard for network-based mobility management.  In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes.  The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered.  This document describes the problem space of localized routing in Proxy Mobile IPv6.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-netext-pmip6-lr-ps-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6279</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6280</doc-id>
        <title>An Architecture for Location and Location Privacy in Internet Applications</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>M. Lepinski</name>
        </author>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>geolocation</kw>
            <kw>geopriv</kw>
        </keywords>
        <abstract><p>Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities.  These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved.  This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-geopriv-arch-03</draft>
        <updates>
            <doc-id>RFC3693</doc-id>
            <doc-id>RFC3694</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0160</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6280</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6281</doc-id>
        <title>Understanding Apple's Back to My Mac (BTMM) Service</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>Z. Zhu</name>
        </author>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service.  BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road.  The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-zhu-mobileme-doc-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6281</errata-url>
        <doi>10.17487/RFC6281</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6282</doc-id>
        <title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
        <author>
            <name>J. Hui</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>LLN</kw>
            <kw>Low Power</kw>
            <kw>radio 802.15.4</kw>
            <kw>powerline</kw>
            <kw>ISA100.11a</kw>
            <kw>RFC 4944</kw>
        </keywords>
        <abstract><p>This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks".  This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs).  The compression format relies on shared context to allow compression of arbitrary prefixes.  How the information is maintained in that shared context is out of scope.  This document specifies compression of multicast addresses and a framework for compressing next headers.  UDP header compression is specified within this framework. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6lowpan-hc-15</draft>
        <updates>
            <doc-id>RFC4944</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8066</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lowpan</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6282</errata-url>
        <doi>10.17487/RFC6282</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6283</doc-id>
        <title>Extensible Markup Language Evidence Record Syntax (XMLERS)</title>
        <author>
            <name>A. Jerman Blazic</name>
        </author>
        <author>
            <name>S. Saljic</name>
        </author>
        <author>
            <name>T. Gondrom</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>long term</kw>
            <kw>trust</kw>
            <kw>integrity</kw>
            <kw>long term integrity</kw>
            <kw>data preservation</kw>
            <kw>document preservation</kw>
            <kw>time-stamp</kw>
            <kw>time-stamping</kw>
            <kw>archive time stamp</kw>
            <kw>electronic archive</kw>
            <kw>electronic archiving</kw>
            <kw>trusted archiving</kw>
            <kw>long-term archive</kw>
            <kw>archive data</kw>
            <kw>evidence</kw>
            <kw>evidence record</kw>
            <kw>evidence record syntax</kw>
            <kw>hash tree</kw>
            <kw>ERS</kw>
            <kw>XML</kw>
            <kw>hash</kw>
            <kw>signature</kw>
            <kw>renewal</kw>
            <kw>algorithm</kw>
            <kw>cryptography</kw>
        </keywords>
        <abstract><p>In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time.  This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data.  The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ltans-xmlers-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ltans</wg_acronym>
        <doi>10.17487/RFC6283</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6284</doc-id>
        <title>Port Mapping between Unicast and Multicast RTP Sessions</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>T. Van Caenegem</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Port mapping</kw>
            <kw>port translation</kw>
            <kw>RTP</kw>
            <kw>multicast</kw>
            <kw>NAT</kw>
        </keywords>
        <abstract><p>This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services.  The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6284</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6285</doc-id>
        <title>Unicast-Based Rapid Acquisition of Multicast RTP Sessions</title>
        <author>
            <name>B. Ver Steeg</name>
        </author>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>T. Van Caenegem</name>
        </author>
        <author>
            <name>Z. Vax</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>SSM</kw>
            <kw>multicast</kw>
            <kw>IPTV</kw>
            <kw>fast channel change</kw>
        </keywords>
        <abstract><p>When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.</p><p> In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-rapid-acquisition-for-rtp-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avt</wg_acronym>
        <doi>10.17487/RFC6285</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6286</doc-id>
        <title>Autonomous-System-Wide Unique BGP Identifier for BGP-4</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>J. Yuan</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
        </keywords>
        <abstract><p>To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required.  These revisions to the base BGP specification do not introduce any backward compatibility issues.  This document updates RFC 4271. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-bgp-identifier-14</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6286</errata-url>
        <doi>10.17487/RFC6286</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6287</doc-id>
        <title>OCRA: OATH Challenge-Response Algorithm</title>
        <author>
            <name>D. M'Raihi</name>
        </author>
        <author>
            <name>J. Rydell</name>
        </author>
        <author>
            <name>S. Bajaj</name>
        </author>
        <author>
            <name>S. Machani</name>
        </author>
        <author>
            <name>D. Naccache</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>HOTP</kw>
            <kw>TOTP</kw>
            <kw>One-Time Password</kw>
            <kw>Authentication</kw>
            <kw>Signature</kw>
        </keywords>
        <abstract><p>This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH).  The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mraihi-mutual-oath-hotp-variants-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6287</errata-url>
        <doi>10.17487/RFC6287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6288</doc-id>
        <title>URN Namespace for the Defence Geospatial Information Working Group (DGIWG)</title>
        <author>
            <name>C. Reed</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Namespace Identifier</kw>
            <kw>nid</kw>
            <kw>DGIWG Registry System</kw>
            <kw>drs</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) Namespace resources published by the Defence Geospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.</p><p> Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-reed-urn-dgiwg-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6288</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6289</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for CableLabs</title>
        <author>
            <name>E. Cardona</name>
        </author>
        <author>
            <name>S. Channabasappa</name>
        </author>
        <author>
            <name>J-F. Mule</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>namespace identifier</kw>
            <kw>nid</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs).  CableLabs specifies and manages resources that utilize this URN identification model.  Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-cardona-cablelabs-urn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6289</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6290</doc-id>
        <title>A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)</title>
        <author>
            <name>Y. Nir</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Wierbowski</name>
        </author>
        <author>
            <name>F. Detienne</name>
        </author>
        <author>
            <name>P. Sethi</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>QCD</kw>
        </keywords>
        <abstract><p>This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.</p><p> When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-failure-detection-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6290</errata-url>
        <doi>10.17487/RFC6290</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6291</doc-id>
        <title>Guidelines for the Use of the "OAM" Acronym in the IETF</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>S. Mansfield</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.</p><p> This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-opsawg-mpls-tp-oam-def-10</draft>
        <is-also>
            <doc-id>BCP0161</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC6291</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6292</doc-id>
        <title>Requirements for a Working Group Charter Tool</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups.  The tool will also allow the IETF community to view the status of the chartering process.  This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-genarea-charter-tool-09</draft>
        <updated-by>
            <doc-id>RFC6433</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6292</errata-url>
        <doi>10.17487/RFC6292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6293</doc-id>
        <title>Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-genarea-datatracker-community-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6293</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6294</doc-id>
        <title>Survey of Proposed Use Cases for the IPv6 Flow Label</title>
        <author>
            <name>Q. Hu</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Quality of service</kw>
            <kw>QoS</kw>
        </keywords>
        <abstract><p>The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice.  This paper describes the flow label standard and discusses the implementation issues that it raises.  It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard.  Methods to address this problem are briefly reviewed.  We also question whether the standard should be revised.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-hu-flow-label-cases-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6294</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6295</doc-id>
        <title>RTP Payload Format for MIDI</title>
        <author>
            <name>J. Lazzaro</name>
        </author>
        <author>
            <name>J. Wawrzynek</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>171</page-count>
        <keywords>
            <kw>asc</kw>
            <kw>content streaming</kw>
            <kw>DLS 2</kw>
            <kw>General MIDI</kw>
            <kw>MIDI</kw>
            <kw>MIDI file</kw>
            <kw>MIDI file streaming</kw>
            <kw>MIDI light control</kw>
            <kw>MIDI rendering</kw>
            <kw>MIDI ringtone</kw>
            <kw>MIDI streaming MIDI sequencer</kw>
            <kw>MIDI time code</kw>
            <kw>MIDI timecode</kw>
            <kw>MIDI Manufacturers Association</kw>
            <kw>MMA mpeg4generic MPEG 4</kw>
            <kw>MPEG 4 Structured Audio</kw>
            <kw>MPEG 4 Synthetic Coding</kw>
            <kw>MTC</kw>
            <kw>musical notes</kw>
            <kw>network musical performance</kw>
            <kw>recovery journal</kw>
            <kw>Show Control</kw>
            <kw>sonification</kw>
            <kw>ringtone</kw>
            <kw>rtpmidi</kw>
            <kw>RTP</kw>
            <kw>RTP MIDI</kw>
            <kw>SMPTE time code</kw>
            <kw>SMPTE timecode</kw>
            <kw>Standard MIDI Files</kw>
            <kw>XMF</kw>
        </keywords>
        <abstract><p>This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language.  The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable.  The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming).  The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss.  Stream behavior, including the MIDI rendering method, may be customized during session setup.  The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio.  This document obsoletes RFC 4695. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-payload-rfc4695-bis-02</draft>
        <obsoletes>
            <doc-id>RFC4695</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6295</errata-url>
        <doi>10.17487/RFC6295</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6296</doc-id>
        <title>IPv6-to-IPv6 Network Prefix Translation</title>
        <author>
            <name>M. Wasserman</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-mrw-nat66-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6296</errata-url>
        <doi>10.17487/RFC6296</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6297</doc-id>
        <title>A Survey of Lower-than-Best-Effort Transport Protocols</title>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>D. Ros</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Less-than-Best-Effort</kw>
            <kw>Congestion Control</kw>
            <kw>LEDBAT</kw>
        </keywords>
        <abstract><p>This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it.  Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best-effort service.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ledbat-survey-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ledbat</wg_acronym>
        <doi>10.17487/RFC6297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6298</doc-id>
        <title>Computing TCP's Retransmission Timer</title>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>J. Chu</name>
        </author>
        <author>
            <name>M. Sargent</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RTO</kw>
        </keywords>
        <abstract><p>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-paxson-tcpm-rfc2988bis-02</draft>
        <obsoletes>
            <doc-id>RFC2988</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1122</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6298</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6299</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6300</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6301</doc-id>
        <title>A Survey of Mobility Support in the Internet</title>
        <author>
            <name>Z. Zhu</name>
        </author>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions.  We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support.  This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-zhu-mobility-survey-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6301</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6302</doc-id>
        <title>Logging Recommendations for Internet-Facing Servers</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>I. Gashinsky</name>
        </author>
        <author>
            <name>D. Lee</name>
        </author>
        <author>
            <name>S. Sheppard</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>port logging</kw>
        </keywords>
        <abstract><p>In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-intarea-server-logging-recommendations-04</draft>
        <is-also>
            <doc-id>BCP0162</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC6302</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6303</doc-id>
        <title>Locally Served DNS Zones</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>AS112</kw>
            <kw> Reverse</kw>
            <kw> IN-ADDR.ARPA</kw>
            <kw> IP6.ARPA</kw>
            <kw> RFC1918</kw>
        </keywords>
        <abstract><p>Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise.  RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-dnsop-default-local-zones-15</draft>
        <is-also>
            <doc-id>BCP0163</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC6303</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6304</doc-id>
        <title>AS112 Nameserver Operations</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>W. Maton</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>RFC1918</kw>
        </keywords>
        <abstract><p>Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.</p><p> Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.</p><p> It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.</p><p> This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-dnsop-as112-ops-09</draft>
        <obsoleted-by>
            <doc-id>RFC7534</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC6304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6305</doc-id>
        <title>I'm Being Attacked by PRISONER.IANA.ORG!</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>W. Maton</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.</p><p> Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.</p><p> Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.</p><p> This document provides background information and technical advice to those firewall operators. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-dnsop-as112-under-attack-help-help-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC6305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6306</doc-id>
        <title>Hierarchical IPv4 Framework</title>
        <author>
            <name>P. Frejborg</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>core address space</kw>
            <kw>area locators</kw>
            <kw>alocs</kw>
            <kw>edge address space</kw>
            <kw>endpoint locators</kw>
            <kw>elocs</kw>
        </keywords>
        <abstract><p>This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.</p><p> This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-frejborg-hipv4-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6306</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6307</doc-id>
        <title>Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks</title>
        <author>
            <name>D. Black</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Dunbar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Roth</name>
        </author>
        <author>
            <name>R. Solomon</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
        </keywords>
        <abstract><p>A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network.  This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services.  This document specifies the encapsulation of Fibre Channel traffic within a pseudowire.  It also specifies the common procedures for using a PW to provide a Fibre Channel service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-fc-encap-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6307</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6308</doc-id>
        <title>Overview of the Internet Multicast Addressing Architecture</title>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>assignment</kw>
            <kw>allocation</kw>
            <kw>SSM</kw>
            <kw>ASM</kw>
            <kw>GLOP</kw>
        </keywords>
        <abstract><p>The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion.  To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mboned-addrarch-07</draft>
        <obsoletes>
            <doc-id>RFC2908</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC6308</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6309</doc-id>
        <title>IANA Rules for MIKEY (Multimedia Internet KEYing)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>J. Mattsson</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>short-term key message</kw>
            <kw>long-term key message</kw>
            <kw>oma</kw>
            <kw>bac</kw>
            <kw>browser and content</kw>
            <kw>broadcast</kw>
        </keywords>
        <abstract><p>This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY).  This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-arkko-mikey-iana-01</draft>
        <obsoletes>
            <doc-id>RFC4909</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3830</doc-id>
            <doc-id>RFC4563</doc-id>
            <doc-id>RFC5410</doc-id>
            <doc-id>RFC6043</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6309</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6310</doc-id>
        <title>Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping</title>
        <author>
            <name>M. Aissaoui</name>
        </author>
        <author>
            <name>P. Busschbach</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>M. Morrow</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>Y(J). Stein</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>interworking</kw>
            <kw>defect state</kw>
            <kw>defect indication</kw>
            <kw>pseudowire</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service.  It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects.  It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-oam-msg-map-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6310</errata-url>
        <doi>10.17487/RFC6310</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6311</doc-id>
        <title>Protocol Support for High Availability of IKEv2/IPsec</title>
        <author>
            <name>R. Singh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Kalyani</name>
        </author>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IPsec high availability</kw>
            <kw>load sharing</kw>
            <kw>clustering</kw>
            <kw>fail-over</kw>
        </keywords>
        <abstract><p>The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.</p><p> This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipsecme-ipsecha-protocol-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6311</errata-url>
        <doi>10.17487/RFC6311</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6312</doc-id>
        <title>Mobile Networks Considerations for IPv6 Deployment</title>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks.  This document discusses the issues that arise when deploying IPv6 in mobile networks.  Hence, this document can be a useful reference for service providers and network designers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-v6-in-mobile-networks-05</draft>
        <obsoleted-by>
            <doc-id>RFC6342</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6312</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6313</doc-id>
        <title>Export of Structured Data in IP Flow Information Export (IPFIX)</title>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>G. Dhandapani</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>S. Yates</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>ipfix information model</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records.  This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates.  Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-structured-data-06</draft>
        <updates>
            <doc-id>RFC5102</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6313</errata-url>
        <doi>10.17487/RFC6313</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6314</doc-id>
        <title>NAT Traversal Practices for Client-Server SIP</title>
        <author>
            <name>C. Boulton</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <abstract><p>Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem.  Currently, there are many deployment scenarios and traversal mechanisms for media traffic.  This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipping-nat-scenarios-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6314</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6315</doc-id>
        <title>IANA Registration for Enumservice 'iax'</title>
        <author>
            <name>E. Guy</name>
        </author>
        <author>
            <name>K. Darilion</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ENUM</kw>
            <kw>E.164</kw>
            <kw>VoIP</kw>
            <kw>Voice over IP</kw>
        </keywords>
        <abstract><p>This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC 6117.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-enum-iax-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>enum</wg_acronym>
        <doi>10.17487/RFC6315</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6316</doc-id>
        <title>Sockets Application Program Interface (API) for Multihoming Shim</title>
        <author>
            <name>M. Komu</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>K. Slavov</name>
        </author>
        <author>
            <name>S. Sugimoto</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Shim6</kw>
            <kw>HIP</kw>
            <kw>identifier/locator split</kw>
        </keywords>
        <abstract><p>This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.</p><p> This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP). This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-shim6-multihome-shim-api-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>shim6</wg_acronym>
        <doi>10.17487/RFC6316</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6317</doc-id>
        <title>Basic Socket Interface Extensions for the Host Identity Protocol (HIP)</title>
        <author>
            <name>M. Komu</name>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>host identity tag</kw>
            <kw>cryptographic identity</kw>
            <kw>cryptographic namespace</kw>
            <kw>sockets API</kw>
            <kw>Shim6</kw>
            <kw>opportunistic mode</kw>
            <kw>resolver</kw>
            <kw>HIP wildcard address</kw>
            <kw>ORCHID</kw>
            <kw>source address selection</kw>
            <kw>HIT prefix</kw>
            <kw>locator handling</kw>
        </keywords>
        <abstract><p>This document defines extensions to the current sockets API for the Host Identity Protocol (HIP).  The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators.  With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies.  The extensions in this document are experimental and provide basic tools for further experimentation with policies.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-hip-native-api-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC6317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6318</doc-id>
        <title>Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>June</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751.  This document obsoletes RFC 5008.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-housley-rfc5008bis-01</draft>
        <obsoletes>
            <doc-id>RFC5008</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6318</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6319</doc-id>
        <title>Issues Associated with Designating Additional Private IPv4 Address Space</title>
        <author>
            <name>M. Azinger</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>private network</kw>
        </keywords>
        <abstract><p>When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.</p><p> While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-azinger-additional-private-ipv4-space-issues-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6319</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6320</doc-id>
        <title>Protocol for Access Node Control Mechanism in Broadband Networks</title>
        <author>
            <name>S. Wadhwa</name>
        </author>
        <author>
            <name>J. Moisand</name>
        </author>
        <author>
            <name>T. Haag</name>
        </author>
        <author>
            <name>N. Voigt</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>ancp</kw>
        </keywords>
        <abstract><p>This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.</p><p> ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ancp-protocol-17</draft>
        <updated-by>
            <doc-id>RFC7256</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ancp</wg_acronym>
        <doi>10.17487/RFC6320</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6321</doc-id>
        <title>xCal: The XML Format for iCalendar</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>M. Douglass</name>
        </author>
        <author>
            <name>S. Lees</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract><p>This specification defines "xCal", an XML format for iCalendar data. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-daboo-et-al-icalendar-in-xml-11</draft>
        <updated-by>
            <doc-id>RFC6868</doc-id>
            <doc-id>RFC7529</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6321</errata-url>
        <doi>10.17487/RFC6321</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6322</doc-id>
        <title>Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent Submissions Editor.  The states and annotations that are to be added to the Datatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventual RFC, and will continue through the lifetime of the Internet-Draft.  The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of these Internet-Drafts and the streams from which they originate.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-hoffman-alt-streams-tracker-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6322</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6323</doc-id>
        <title>Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)</title>
        <author>
            <name>G. Renker</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DCCP</kw>
            <kw>TFRC</kw>
            <kw>CCID-3</kw>
            <kw>CCID-4</kw>
        </keywords>
        <abstract><p>This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.</p><p> The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.</p><p> It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-tfrc-rtt-option-06</draft>
        <updates>
            <doc-id>RFC4342</doc-id>
            <doc-id>RFC5622</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <doi>10.17487/RFC6323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6324</doc-id>
        <title>Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations</title>
        <author>
            <name>G. Nakibly</name>
        </author>
        <author>
            <name>F. Templin</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Encapsulation</kw>
            <kw>ISATAP</kw>
            <kw>6rd</kw>
        </keywords>
        <abstract><p>This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels.  These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state.  The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks.  The first aim of this document is to inform on this attack and its root causes.  The second aim is to present some possible mitigation measures.  It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities.  Nonetheless, these vulnerabilities can be activated by accidental misconfiguration.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-tunnel-loops-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6324</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6325</doc-id>
        <title>Routing Bridges (RBridges): Base Protocol Specification</title>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <keywords>
            <kw>TRILL</kw>
        </keywords>
        <abstract><p>Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.</p><p> RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.</p><p> The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-trill-rbridge-protocol-16</draft>
        <updated-by>
            <doc-id>RFC6327</doc-id>
            <doc-id>RFC6439</doc-id>
            <doc-id>RFC7172</doc-id>
            <doc-id>RFC7177</doc-id>
            <doc-id>RFC7357</doc-id>
            <doc-id>RFC7179</doc-id>
            <doc-id>RFC7180</doc-id>
            <doc-id>RFC7455</doc-id>
            <doc-id>RFC7780</doc-id>
            <doc-id>RFC7783</doc-id>
            <doc-id>RFC8139</doc-id>
            <doc-id>RFC8249</doc-id>
            <doc-id>RFC8361</doc-id>
            <doc-id>RFC8377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6325</errata-url>
        <doi>10.17487/RFC6325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6326</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS</title>
        <author>
            <name>D. Eastlake</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>RBridge</kw>
            <kw>IS-IS</kw>
            <kw>ISIS</kw>
        </keywords>
        <abstract><p>The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing.  This document specifies the data formats and code points for the IS-IS extensions to support TRILL. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-trill-05</draft>
        <obsoleted-by>
            <doc-id>RFC7176</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6326</errata-url>
        <doi>10.17487/RFC6326</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6327</doc-id>
        <title>Routing Bridges (RBridges): Adjacency</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>RBridge</kw>
            <kw>TRILL</kw>
            <kw>Adjacency</kw>
        </keywords>
        <abstract><p>The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).</p><p> TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-trill-adj-07</draft>
        <obsoleted-by>
            <doc-id>RFC7177</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7180</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC6327</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6328</doc-id>
        <title>IANA Considerations for Network Layer Protocol Identifiers</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>NLPID</kw>
        </keywords>
        <abstract><p>Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID).  This document provides NLPID IANA considerations.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-eastlake-nlpid-iana-considerations-04</draft>
        <is-also>
            <doc-id>BCP0164</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6328</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6329</doc-id>
        <title>IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging</title>
        <author>
            <name>D. Fedyk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Ashwood-Smith</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Allan</name>
        </author>
        <author>
            <name>A. Bragg</name>
        </author>
        <author>
            <name>P. Unbehagen</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>spb</kw>
        </keywords>
        <abstract><p>802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols.  802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths.  This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology.  Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations.  This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isis-ieee-aq-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6329</errata-url>
        <doi>10.17487/RFC6329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6330</doc-id>
        <title>RaptorQ Forward Error Correction Scheme for Object Delivery</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>A. Shokrollahi</name>
        </author>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <author>
            <name>L. Minder</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>FEC code</kw>
            <kw>fountain code</kw>
            <kw>systematic code</kw>
            <kw>AL FEC code</kw>
            <kw>Sub-blocking</kw>
            <kw>FEC object delivery</kw>
        </keywords>
        <abstract><p>This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.</p><p> RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.</p><p> The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-bb-fec-raptorq-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6330</errata-url>
        <doi>10.17487/RFC6330</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6331</doc-id>
        <title>Moving DIGEST-MD5 to Historic</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>http</kw>
            <kw>hypertext transfer protocol</kw>
            <kw>security</kw>
            <kw>simple</kw>
            <kw>layer</kw>
        </keywords>
        <abstract><p>This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831.  It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-kitten-digest-to-historic-04</draft>
        <obsoletes>
            <doc-id>RFC2831</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC6331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6332</doc-id>
        <title>Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>E. Friedrich</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SSM</kw>
            <kw>multicast</kw>
            <kw>IPTV</kw>
            <kw>RAMS</kw>
            <kw>rapid acquisition</kw>
            <kw>fast channel change</kw>
        </keywords>
        <abstract><p>In most RTP-based multicast applications, the RTP source sends inter- related data.  Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session.  Thus, they often experience a random acquisition delay.  An RTP receiver can use one or more different approaches to achieve rapid acquisition.  Yet, due to various factors, performance of the rapid acquisition methods usually varies.  Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so).  For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences.  This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611).  This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtext-multicast-acq-rtcp-xr-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC6332</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6333</doc-id>
        <title>Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>J. Woodyatt</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>NAT</kw>
        </keywords>
        <abstract><p>This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks.  Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-dual-stack-lite-11</draft>
        <updated-by>
            <doc-id>RFC7335</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6333</errata-url>
        <doi>10.17487/RFC6333</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6334</doc-id>
        <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite</title>
        <author>
            <name>D. Hankins</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Softwire</kw>
            <kw>DS-Lite</kw>
        </keywords>
        <abstract><p>This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-ds-lite-tunnel-option-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC6334</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6335</doc-id>
        <title>Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry</title>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>transport</kw>
            <kw>ports</kw>
            <kw>port numbers</kw>
            <kw>allocation</kw>
            <kw>assignment</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract><p>This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.</p><p> This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-tsvwg-iana-ports-10</draft>
        <updates>
            <doc-id>RFC2780</doc-id>
            <doc-id>RFC2782</doc-id>
            <doc-id>RFC3828</doc-id>
            <doc-id>RFC4340</doc-id>
            <doc-id>RFC4960</doc-id>
            <doc-id>RFC5595</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0165</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6335</errata-url>
        <doi>10.17487/RFC6335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6336</doc-id>
        <title>IANA Registry for Interactive Connectivity Establishment (ICE) Options</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>It has been identified that "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE options.  This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-ice-options-registry-02</draft>
        <obsoleted-by>
            <doc-id>RFC8839</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5245</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC6336</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6337</doc-id>
        <title>Session Initiation Protocol (SIP) Usage of the Offer/Answer Model</title>
        <author>
            <name>S. Okumura</name>
        </author>
        <author>
            <name>T. Sawada</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>answer</kw>
            <kw>offer</kw>
            <kw>SDP</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP).  The description of the offer/answer model in SIP is dispersed across multiple RFCs.  This document summarizes all the current usages of the offer/answer model in SIP communication.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sipping-sip-offeranswer-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6337</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6338</doc-id>
        <title>Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)</title>
        <author>
            <name>V. Giralt</name>
        </author>
        <author>
            <name>R. McDuff</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TERENA</kw>
            <kw>tf-emc2</kw>
        </keywords>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).</p><p> The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-giralt-schac-ns-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6338</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6339</doc-id>
        <title>Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API)</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>L. Hornquist Astrand</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs.  This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-josefsson-gss-capsulate-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6339</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6340</doc-id>
        <title>Textual Conventions for the Representation of Floating-Point Numbers</title>
        <author>
            <name>R. Presuhn</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>IEEE 754</kw>
            <kw>Floating-point</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>Textual Convention</kw>
            <kw>FLOAT-TC-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-opsawg-mib-floats-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC6340</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6341</doc-id>
        <title>Use Cases and Requirements for SIP-Based Media Recording (SIPREC)</title>
        <author>
            <name>K. Rehor</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Portman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Hutton</name>
        </author>
        <author>
            <name>R. Jain</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.</p><p> Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-siprec-req-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>siprec</wg_acronym>
        <doi>10.17487/RFC6341</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6342</doc-id>
        <title>Mobile Networks Considerations for IPv6 Deployment</title>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks.  This document discusses the issues that arise when deploying IPv6 in mobile networks.  Hence, this document can be a useful reference for service providers and network designers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-v6-in-mobile-networks-rfc6312bis</draft>
        <obsoletes>
            <doc-id>RFC6312</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6342</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6343</doc-id>
        <title>Advisory Guidelines for 6to4 Deployment</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IPv6 relay</kw>
        </keywords>
        <abstract><p>This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4.  It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers.  Some advice to implementers is also included.  The intention of the advice is to minimize both user dissatisfaction and help-desk calls.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-6to4-advisory-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6344</doc-id>
        <title>Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)</title>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>R. Rabbat</name>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS).  LCAS can be used for hitless dynamic resizing of the inverse multiplex group.  These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.  This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-vcat-lcas-13</draft>
        <updates>
            <doc-id>RFC4606</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6344</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6345</doc-id>
        <title>Protocol for Carrying Authentication for Network Access (PANA) Relay Element</title>
        <author>
            <name>P. Duffy</name>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>R. Cragie</name>
        </author>
        <author>
            <name>Y. Ohba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>ZigBee</kw>
        </keywords>
        <abstract><p>This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ohba-pana-relay-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6345</errata-url>
        <doi>10.17487/RFC6345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6346</doc-id>
        <title>The Address plus Port (A+P) Approach to the IPv4 Address Shortage</title>
        <author>
            <name>R. Bush</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.</p><p> This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ymbk-aplusp-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6347</doc-id>
        <title>Datagram Transport Layer Security Version 1.2</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>N. Modadugu</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>dtls</kw>
            <kw>dtls protocol</kw>
        </keywords>
        <abstract><p>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-rfc4347-bis-06</draft>
        <obsoletes>
            <doc-id>RFC4347</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9147</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7507</doc-id>
            <doc-id>RFC7905</doc-id>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9146</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6347</errata-url>
        <doi>10.17487/RFC6347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6348</doc-id>
        <title>Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol</title>
        <author>
            <name>JL. Le Roux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Morin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LDP</kw>
            <kw>multipoint</kw>
            <kw>P2MP</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.</p><p> This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-ietf-mpls-mp-ldp-reqs-08</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6348</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6349</doc-id>
        <title>Framework for TCP Throughput Testing</title>
        <author>
            <name>B. Constantine</name>
        </author>
        <author>
            <name>G. Forget</name>
        </author>
        <author>
            <name>R. Geib</name>
        </author>
        <author>
            <name>R. Schrage</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>metric</kw>
            <kw>TCP testing</kw>
        </keywords>
        <abstract><p>This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network.  The goal is to provide a better indication in regard to user experience.  In this framework, TCP and IP parameters are specified to optimize TCP Throughput.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ippm-tcp-throughput-tm-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6349</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6350</doc-id>
        <title>vCard Format Specification</title>
        <author>
            <name>S. Perreault</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>vCard</kw>
        </keywords>
        <abstract><p>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-vcardrev-22</draft>
        <obsoletes>
            <doc-id>RFC2425</doc-id>
            <doc-id>RFC2426</doc-id>
            <doc-id>RFC4770</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2739</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC6868</doc-id>
            <doc-id>RFC9554</doc-id>
            <doc-id>RFC9555</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6350</errata-url>
        <doi>10.17487/RFC6350</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6351</doc-id>
        <title>xCard: vCard XML Representation</title>
        <author>
            <name>S. Perreault</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>vCard</kw>
        </keywords>
        <abstract><p>This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-vcardxml-11</draft>
        <updated-by>
            <doc-id>RFC6868</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6351</errata-url>
        <doi>10.17487/RFC6351</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6352</doc-id>
        <title>CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>address</kw>
            <kw>address book</kw>
            <kw>contact</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-carddav-10</draft>
        <updated-by>
            <doc-id>RFC6764</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6352</errata-url>
        <doi>10.17487/RFC6352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6353</doc-id>
        <title>Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>July</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>dtls</kw>
            <kw>datagram transport layer security</kw>
            <kw>tls transport model</kw>
            <kw>tlstm</kw>
            <kw>SNMP-TLS-TM-MIB</kw>
        </keywords>
        <abstract><p>This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.</p><p> This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.</p><p> This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-isms-dtls-tm-rfc5953bis-00</draft>
        <obsoletes>
            <doc-id>RFC5953</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9456</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0078</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>isms</wg_acronym>
        <doi>10.17487/RFC6353</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6354</doc-id>
        <title>Forward-Shifted RTP Redundancy Payload Support</title>
        <author>
            <name>Q. Xie</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data.  Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avt-forward-shifted-red-08</draft>
        <updates>
            <doc-id>RFC2198</doc-id>
            <doc-id>RFC4102</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6354</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6355</doc-id>
        <title>Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>J. Johnson</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>universally unique identifier</kw>
        </keywords>
        <abstract><p>This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID.  DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format.  DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa.  UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-duid-uuid-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6355</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6356</doc-id>
        <title>Coupled Congestion Control for Multipath Transport Protocols</title>
        <author>
            <name>C. Raiciu</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>D. Wischik</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>multipath</kw>
            <kw>tcp</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.</p><p> New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.</p><p> This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mptcp-congestion-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6356</errata-url>
        <doi>10.17487/RFC6356</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6357</doc-id>
        <title>Design Considerations for Session Initiation Protocol (SIP) Overload Control</title>
        <author>
            <name>V. Hilt</name>
        </author>
        <author>
            <name>E. Noel</name>
        </author>
        <author>
            <name>C. Shen</name>
        </author>
        <author>
            <name>A. Abdelal</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Session Initiation Protocol</kw>
            <kw>Overload Control</kw>
            <kw>Congestion Collapse</kw>
        </keywords>
        <abstract><p>Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive.  Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload.  This document discusses models and design considerations for a SIP overload control mechanism.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-soc-overload-design-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>soc</wg_acronym>
        <doi>10.17487/RFC6357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6358</doc-id>
        <title>Additional Master Secret Inputs for TLS</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>tls</kw>
            <kw>dtls</kw>
            <kw>datagram tls</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS).  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-hoffman-tls-master-secret-input-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6358</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6359</doc-id>
        <title>Datatracker Extensions to Include IANA and RFC Editor Processing Information</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>A. Morris</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>id-tracker</kw>
            <kw>backend extensions</kw>
        </keywords>
        <abstract><p>This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC.  Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay.  Therefore, this document also describes the requirements to make such automation possible.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-genarea-datatracker-iana-rfced-extns-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6359</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6360</doc-id>
        <title>Conclusion of FYI RFC Sub-Series</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists.  The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision.  This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iesg-rfc1150bis-01</draft>
        <obsoletes>
            <doc-id>RFC1150</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6360</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6361</doc-id>
        <title>PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol</title>
        <author>
            <name>J. Carlson</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>point-to-point protocol</kw>
            <kw>rbridges</kw>
            <kw>routing bridges</kw>
        </keywords>
        <abstract><p>The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links.  This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pppext-trill-protocol-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6362</doc-id>
        <title>Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)</title>
        <author>
            <name>K. Meadors</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>EDIINT</kw>
            <kw>AS2</kw>
            <kw>Multiple</kw>
            <kw>Attachments</kw>
        </keywords>
        <abstract><p>The Electronic Data Interchange - Internet Integration (EDIINT) AS1, AS2, and AS3 messages were designed specifically for the transport of EDI documents.  Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message.  As adoption of EDIINT grew, other uses developed aside from single EDI document transport.  Some transactions required multiple attachments to be interpreted together and stored in a single message.  This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message.  The attachments are stored within the MIME multipart/related structure.  A minimal list of content-types to be supported as attachments is provided.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-meadors-multiple-attachments-ediint-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6362</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6363</doc-id>
        <title>Forward Error Correction (FEC) Framework</title>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>V. Roca</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>Reliable streaming</kw>
            <kw>content delivery</kw>
            <kw>FEC schemes</kw>
        </keywords>
        <abstract><p>This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss.  The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media.  This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows.  Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document.  Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fecframe-framework-15</draft>
        <updated-by>
            <doc-id>RFC8680</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6363</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6364</doc-id>
        <title>Session Description Protocol Elements for the Forward Error Correction (FEC) Framework</title>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>FEC configuration</kw>
            <kw>FEC topologies</kw>
        </keywords>
        <abstract><p>This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s).  This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fecframe-sdp-elements-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6364</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6365</doc-id>
        <title>Terminology Used in Internationalization in the IETF</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>i18n</kw>
            <kw>vocabulary</kw>
            <kw>terms</kw>
        </keywords>
        <abstract><p>This document provides a list 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 documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-appsawg-rfc3536bis-06</draft>
        <obsoletes>
            <doc-id>RFC3536</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0166</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6365</errata-url>
        <doi>10.17487/RFC6365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6366</doc-id>
        <title>Requirements for an Internet Audio Codec</title>
        <author>
            <name>J. Valin</name>
        </author>
        <author>
            <name>K. Vos</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document provides specific requirements for an Internet audio codec.  These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-codec-requirements-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>codec</wg_acronym>
        <doi>10.17487/RFC6366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6367</doc-id>
        <title>Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)</title>
        <author>
            <name>S. Kanno</name>
        </author>
        <author>
            <name>M. Kanda</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>GCM</kw>
            <kw>Eliptic Curve Encryption</kw>
            <kw>Block Cipher</kw>
            <kw>psk</kw>
        </keywords>
        <abstract><p>This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-kanno-tls-camellia-03</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6367</errata-url>
        <doi>10.17487/RFC6367</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6368</doc-id>
        <title>Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)</title>
        <author>
            <name>P. Marques</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <author>
            <name>T. Yamagata</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>l3vpn</kw>
            <kw>iBGP</kw>
            <kw>loops</kw>
            <kw>as-override</kw>
            <kw>attribute set</kw>
            <kw>attr_set</kw>
        </keywords>
        <abstract><p>This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs.  These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-ibgp-08</draft>
        <updated-by>
            <doc-id>RFC7606</doc-id>
            <doc-id>RFC9494</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6368</errata-url>
        <doi>10.17487/RFC6368</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6369</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Implementation Experience</title>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>O. Koufopavlou</name>
        </author>
        <author>
            <name>S. Denazis</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE).  This document captures the experience of implementing the ForCES protocol and model.  Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-haleplidis-forces-implementation-experience-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6370</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Identifiers</title>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-identifiers-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6370</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6371</doc-id>
        <title>Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks</title>
        <author>
            <name>I. Busi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Allan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <abstract><p>The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.</p><p> This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.</p><p> This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-oam-framework-11</draft>
        <updated-by>
            <doc-id>RFC6435</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6371</errata-url>
        <doi>10.17487/RFC6371</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6372</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Survivability Framework</title>
        <author>
            <name>N. Sprecher</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>Protection</kw>
            <kw>Restoration</kw>
            <kw>Recovery</kw>
        </keywords>
        <abstract><p>Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.</p><p> The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.</p><p> This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.</p><p> This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-survive-fwk-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6373</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Control Plane Framework</title>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Fang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Bitar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Gray</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <abstract><p>The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.</p><p> This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ccamp-mpls-tp-cp-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6373</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6374</doc-id>
        <title>Packet Loss and Delay Measurement for MPLS Networks</title>
        <author>
            <name>D. Frost</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
        </keywords>
        <abstract><p>Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput.  This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation.  This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-loss-delay-04</draft>
        <updated-by>
            <doc-id>RFC7214</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6374</errata-url>
        <doi>10.17487/RFC6374</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6375</doc-id>
        <title>A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks</title>
        <author>
            <name>D. Frost</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.</p><p> The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.</p><p> This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-loss-delay-profile-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6375</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6376</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Signatures</title>
        <author>
            <name>D. Crocker</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Hansen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>email</kw>
            <kw>architecture</kw>
            <kw>abuse</kw>
            <kw>verification</kw>
            <kw>anti-abuse</kw>
            <kw>identity</kw>
            <kw>integrity</kw>
            <kw>responsible</kw>
            <kw>author</kw>
            <kw>sender</kw>
            <kw>originator</kw>
            <kw>email filtering</kw>
            <kw>anti-phishing</kw>
            <kw>mail signature</kw>
        </keywords>
        <abstract><p>DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.</p><p> This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dkim-rfc4871bis-15</draft>
        <obsoletes>
            <doc-id>RFC4871</doc-id>
            <doc-id>RFC5672</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8301</doc-id>
            <doc-id>RFC8463</doc-id>
            <doc-id>RFC8553</doc-id>
            <doc-id>RFC8616</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0076</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6376</errata-url>
        <doi>10.17487/RFC6376</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6377</doc-id>
        <title>DomainKeys Identified Mail (DKIM) and Mailing Lists</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>email</kw>
            <kw>architecture</kw>
            <kw>verification</kw>
            <kw>anti-abuse</kw>
            <kw>identity</kw>
            <kw>integrity</kw>
            <kw>responsible</kw>
            <kw>author</kw>
            <kw>sender</kw>
            <kw>originator</kw>
        </keywords>
        <abstract><p>DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message.  Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs).  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-dkim-mailinglists-12</draft>
        <is-also>
            <doc-id>BCP0167</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dkim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6377</errata-url>
        <doi>10.17487/RFC6377</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6378</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Linear Protection</title>
        <author>
            <name>Y. Weingarten</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>E. Osborne</name>
        </author>
        <author>
            <name>N. Sprecher</name>
        </author>
        <author>
            <name>A. Fulignoli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>PSC</kw>
            <kw>Protection State Coordination Protocol,</kw>
        </keywords>
        <abstract><p>This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.</p><p> This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-linear-protection-09</draft>
        <updated-by>
            <doc-id>RFC7214</doc-id>
            <doc-id>RFC7271</doc-id>
            <doc-id>RFC7324</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6378</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6379</doc-id>
        <title>Suite B Cryptographic Suites for IPsec</title>
        <author>
            <name>L. Law</name>
        </author>
        <author>
            <name>J. Solinas</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>UI suites</kw>
            <kw>user interface suites</kw>
            <kw>elliptic curve</kw>
            <kw>ike</kw>
        </keywords>
        <abstract><p>This document proposes four cryptographic user interface suites ("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308.  The four new suites provide compatibility with the United States National Security Agency's Suite B specifications.  This document obsoletes RFC 4869, which presented earlier versions of these suites.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-law-rfc4869bis-01</draft>
        <obsoletes>
            <doc-id>RFC4869</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6379</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6380</doc-id>
        <title>Suite B Profile for Internet Protocol Security (IPsec)</title>
        <author>
            <name>K. Burgin</name>
        </author>
        <author>
            <name>M. Peck</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>cryptographic algorithm policy</kw>
            <kw>security application</kw>
            <kw>suite b cryptography</kw>
        </keywords>
        <abstract><p>The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec).</p><p> Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-burgin-ipsec-suiteb-profile-02</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6380</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6381</doc-id>
        <title>The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>P. Frojdh</name>
        </author>
        <date>
            <month>August</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>codec</kw>
            <kw>container</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>3gpp</kw>
            <kw>3gpp2</kw>
        </keywords>
        <abstract><p>Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered.</p><p> This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.</p><p> By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).</p><p> Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gellens-mime-bucket-bis-09</draft>
        <obsoletes>
            <doc-id>RFC4281</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3839</doc-id>
            <doc-id>RFC4393</doc-id>
            <doc-id>RFC4337</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6381</errata-url>
        <doi>10.17487/RFC6381</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6382</doc-id>
        <title>Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>R. Donnelly</name>
        </author>
        <author>
            <name>F. Scalzo</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>SIDR</kw>
            <kw>RPKI</kw>
            <kw>security</kw>
            <kw>routing</kw>
            <kw>operations</kw>
            <kw>root</kw>
            <kw>TLD</kw>
            <kw>DNS</kw>
            <kw>DDOS</kw>
            <kw>peering</kw>
            <kw>RIR</kw>
            <kw>IRR</kw>
            <kw>MITM</kw>
        </keywords>
        <abstract><p>This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix.  Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-grow-unique-origin-as-01</draft>
        <is-also>
            <doc-id>BCP0169</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6382</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6383</doc-id>
        <title>Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE</title>
        <author>
            <name>K. Shiomoto</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RSVP-TE</kw>
            <kw>GMPLS</kw>
            <kw>MPLS-TE</kw>
            <kw>cross-connect</kw>
            <kw>data plane</kw>
        </keywords>
        <abstract><p>The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.</p><p> End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.</p><p> This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-shiomoto-ccamp-switch-programming-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6383</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6384</doc-id>
        <title>An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation</title>
        <author>
            <name>I. van Beijnum</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>SIIT</kw>
            <kw>NAT64</kw>
        </keywords>
        <abstract><p>The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.</p><p> FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-ftp64-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC6384</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6385</doc-id>
        <title>General Area Review Team (Gen-ART) Experiences</title>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>genart</kw>
        </keywords>
        <abstract><p>The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004.  This document discusses the experience and the lessons learned over the past 7 years of this process.  The review team initially reviewed the I-Ds before each of the IESG telechats.  Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D.  The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-doria-genart-experience-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6385</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6386</doc-id>
        <title>VP8 Data Format and Decoding Guide</title>
        <author>
            <name>J. Bankoski</name>
        </author>
        <author>
            <name>J. Koleszar</name>
        </author>
        <author>
            <name>L. Quillio</name>
        </author>
        <author>
            <name>J. Salonen</name>
        </author>
        <author>
            <name>P. Wilkins</name>
        </author>
        <author>
            <name>Y. Xu</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>304</page-count>
        <abstract><p>This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-bankoski-vp8-bitstream-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6386</errata-url>
        <doi>10.17487/RFC6386</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6387</doc-id>
        <title>GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)</title>
        <author>
            <name>A. Takacs</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>J. Meuric</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>rsvp</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract><p>This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs).  The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters.  This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03</draft>
        <obsoletes>
            <doc-id>RFC5467</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6388</doc-id>
        <title>Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Minei</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>B. Thomas</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.  These extensions are also referred to as multipoint LDP.  Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.  Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner.  There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs).  Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-p2mp-15</draft>
        <updated-by>
            <doc-id>RFC7358</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6388</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6389</doc-id>
        <title>MPLS Upstream Label Assignment for LDP</title>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP).  It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-upstream-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6390</doc-id>
        <title>Guidelines for Considering New Performance Metric Development</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols.  These metrics can be used to characterize traffic on live networks and services.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-pmol-metrics-framework-12</draft>
        <is-also>
            <doc-id>BCP0170</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>pmol</wg_acronym>
        <doi>10.17487/RFC6390</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6391</doc-id>
        <title>Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>U. Drafz</name>
        </author>
        <author>
            <name>V. Kompella</name>
        </author>
        <author>
            <name>J. Regan</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
        </keywords>
        <abstract><p>Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.</p><p> This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-fat-pw-07</draft>
        <updated-by>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6391</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6392</doc-id>
        <title>A Survey of In-Network Storage Systems</title>
        <author>
            <name>R. Alimi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Rahman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Yang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>P2P</kw>
            <kw>DECADE</kw>
            <kw>DECoupled Application Data Enroute</kw>
        </keywords>
        <abstract><p>This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-decade-survey-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>decade</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6392</errata-url>
        <doi>10.17487/RFC6392</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6393</doc-id>
        <title>Moving RFC 4693 to Historic</title>
        <author>
            <name>M. Yevstifeyev</name>
        </author>
        <date>
            <month>September</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>ION</kw>
            <kw>historic</kw>
        </keywords>
        <abstract><p>This document moves RFC 4693 to Historic status.  It also obsoletes RFC 4693.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-yevstifeyev-ion-report-07</draft>
        <obsoletes>
            <doc-id>RFC4693</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6393</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6394</doc-id>
        <title>Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>PKIX</kw>
        </keywords>
        <abstract><p>Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name.  Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself.  This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process.  The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dane-use-cases-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <doi>10.17487/RFC6394</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6395</doc-id>
        <title>An Interface Identifier (ID) Hello Option for PIM</title>
        <author>
            <name>S. Gulrajani</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-hello-intid-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6395</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6396</doc-id>
        <title>Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format</title>
        <author>
            <name>L. Blunk</name>
        </author>
        <author>
            <name>M. Karir</name>
        </author>
        <author>
            <name>C. Labovitz</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the MRT format for routing information export.  This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name.  The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-grow-mrt-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6396</errata-url>
        <doi>10.17487/RFC6396</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6397</doc-id>
        <title>Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions</title>
        <author>
            <name>T. Manderson</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>GPS Coordinates</kw>
            <kw>Terrestrial Coordinates</kw>
            <kw>BGP Speaker</kw>
            <kw>BGP Peer</kw>
            <kw>BGP Latitude</kw>
            <kw>BGP Longitude</kw>
        </keywords>
        <abstract><p>This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-grow-geomrt-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6397</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6398</doc-id>
        <title>IP Router Alert Considerations and Usage</title>
        <author>
            <name>F. Le Faucheur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
        </keywords>
        <abstract><p>The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet.  The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option.  This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711.  Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  It also provides recommendations about protection approaches for service providers.  Finally, it provides brief guidelines for Router Alert implementation on routers.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-intarea-router-alert-considerations-10</draft>
        <updates>
            <doc-id>RFC2113</doc-id>
            <doc-id>RFC2711</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0168</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC6398</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6399</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6400</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6401</doc-id>
        <title>RSVP Extensions for Admission Priority</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>K. Carlberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
        </keywords>
        <abstract><p>Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.</p><p> Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-emergency-rsvp-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6401</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6402</doc-id>
        <title>Certificate Management over CMS (CMC) Updates</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>cyrptographic message syntax</kw>
        </keywords>
        <abstract><p>This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.</p><p> The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc5272-bis-08</draft>
        <updates>
            <doc-id>RFC5272</doc-id>
            <doc-id>RFC5273</doc-id>
            <doc-id>RFC5274</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6402</errata-url>
        <doi>10.17487/RFC6402</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6403</doc-id>
        <title>Suite B Profile of Certificate Management over CMS</title>
        <author>
            <name>L. Zieglar</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>M. Peck</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>cmc</kw>
            <kw>suite b x.509 public key certificates</kw>
        </keywords>
        <abstract><p>The United States government has published guidelines for "NSA Suite\0B Cryptography", which defines cryptographic algorithm policy for national security applications.  This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates.  This profile is a refinement of RFCs 5272, 5273, and 5274.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-turner-suiteb-cmc-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6403</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6404</doc-id>
        <title>Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures</title>
        <author>
            <name>J. Seedorf</name>
        </author>
        <author>
            <name>S. Niccolini</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>H. Scholz</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>VoIP</kw>
            <kw>Security</kw>
            <kw>Threats</kw>
            <kw>multimedia</kw>
            <kw>Threat countermeasures</kw>
            <kw>SIP Interconnect</kw>
            <kw>VoIP peering</kw>
            <kw>Fraud prevention</kw>
            <kw>Network protection</kw>
            <kw>SIP</kw>
            <kw>RTP</kw>
            <kw>RTCP</kw>
            <kw>control plane</kw>
            <kw>user plane</kw>
        </keywords>
        <abstract><p>The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs).  The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures.  Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements.  In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider.  Various instances of the threats are briefly introduced inside the classification.  Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats.  Each SSP may have connections to one or more remote SSPs through peering or transit contracts.  A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-speermint-voipthreats-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speermint</wg_acronym>
        <doi>10.17487/RFC6404</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6405</doc-id>
        <title>Voice over IP (VoIP) SIP Peering Use Cases</title>
        <author>
            <name>A. Uzelac</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>VoIP</kw>
            <kw>SIP Peering</kw>
        </keywords>
        <abstract><p>This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering.  These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect.  These use cases are not an exhaustive set, but rather the most common use cases deployed today.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-speermint-voip-consolidated-usecases-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speermint</wg_acronym>
        <doi>10.17487/RFC6405</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6406</doc-id>
        <title>Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture</title>
        <author>
            <name>D. Malas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Livingood</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces.  It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-speermint-architecture-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speermint</wg_acronym>
        <doi>10.17487/RFC6406</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6407</doc-id>
        <title>The Group Domain of Interpretation</title>
        <author>
            <name>B. Weis</name>
        </author>
        <author>
            <name>S. Rowles</name>
        </author>
        <author>
            <name>T. Hardjono</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547.  The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046.  The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols.  This document replaces RFC 3547. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-msec-gdoi-update-11</draft>
        <obsoletes>
            <doc-id>RFC3547</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>msec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6407</errata-url>
        <doi>10.17487/RFC6407</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6408</doc-id>
        <title>Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>L. Morand</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Services Field</kw>
            <kw>Peer Discovery</kw>
        </keywords>
        <abstract><p>The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol.  However, these mechanisms do not reveal the Diameter applications that each node supports.  A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application.  This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-extended-naptr-09</draft>
        <updates>
            <doc-id>RFC3588</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC6408</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6409</doc-id>
        <title>Message Submission for Mail</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Text</kw>
            <kw>Internationalization</kw>
            <kw>ASCII</kw>
            <kw>Unicode</kw>
            <kw>UTF-8</kw>
        </keywords>
        <abstract><p>This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.</p><p> Message relay is unaffected, and continues to use SMTP over port 25.</p><p> When conforming to this document, message submission uses the protocol specified here, normally over port 587.</p><p> This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-yam-rfc4409bis-03</draft>
        <obsoletes>
            <doc-id>RFC4409</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8314</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0072</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>yam</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6409</errata-url>
        <doi>10.17487/RFC6409</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6410</doc-id>
        <title>Reducing the Standards Track to Two Maturity Levels</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>E. Burger</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026.  Primarily, it reduces the Standards Process from three Standards Track maturity levels to two.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-housley-two-maturity-levels-09</draft>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6410</errata-url>
        <doi>10.17487/RFC6410</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6411</doc-id>
        <title>Applicability of Keying Methods for RSVP Security</title>
        <author>
            <name>M. Behringer</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RSVP authentication</kw>
            <kw>RSVP integrity</kw>
            <kw>Resource reservation protocol</kw>
            <kw>GDOI</kw>
            <kw>Group domain of interpretation</kw>
        </keywords>
        <abstract><p>The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors.  This requires messages to be cryptographically protected using a shared secret between participating nodes.  This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches.  This document also discusses applicability of encrypting RSVP messages.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-security-groupkeying-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6412</doc-id>
        <title>Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence</title>
        <author>
            <name>S. Poretsky</name>
        </author>
        <author>
            <name>B. Imhoff</name>
        </author>
        <author>
            <name>K. Michielsen</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence.  The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements.  The terminology can be applied to any link-state IGP, such as IS-IS and OSPF.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-bmwg-igp-dataplane-conv-term-23</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6412</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6413</doc-id>
        <title>Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence</title>
        <author>
            <name>S. Poretsky</name>
        </author>
        <author>
            <name>B. Imhoff</name>
        </author>
        <author>
            <name>K. Michielsen</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>Interior Gateway Protocol</kw>
        </keywords>
        <abstract><p>This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence.  The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements.  The methodology can be applied to any link-state IGP, such as IS-IS and OSPF.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-bmwg-igp-dataplane-conv-meth-23</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6413</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6414</doc-id>
        <title>Benchmarking Terminology for Protection Performance</title>
        <author>
            <name>S. Poretsky</name>
        </author>
        <author>
            <name>R. Papneja</name>
        </author>
        <author>
            <name>J. Karthik</name>
        </author>
        <author>
            <name>S. Vapiwala</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms.  The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer.  The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-bmwg-protection-term-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6415</doc-id>
        <title>Web Host Metadata</title>
        <author>
            <name>E. Hammer-Lahav</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Cook</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
        </keywords>
        <abstract><p>This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-hammer-hostmeta-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6415</errata-url>
        <doi>10.17487/RFC6415</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6416</doc-id>
        <title>RTP Payload Format for MPEG-4 Audio/Visual Streams</title>
        <author>
            <name>M. Schmidt</name>
        </author>
        <author>
            <name>F. de Bont</name>
        </author>
        <author>
            <name>S. Doehla</name>
        </author>
        <author>
            <name>J. Kim</name>
        </author>
        <date>
            <month>October</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>RFC3016</kw>
            <kw>RTP</kw>
            <kw>MPEG-4</kw>
            <kw>Audio</kw>
            <kw>Visual</kw>
            <kw>Video</kw>
            <kw>AAC</kw>
            <kw>HE AAC</kw>
            <kw>HE AAC v2</kw>
            <kw>MPEG Surround</kw>
        </keywords>
        <abstract><p>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. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.</p><p> For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-payload-rfc3016bis-03</draft>
        <obsoletes>
            <doc-id>RFC3016</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC6416</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6417</doc-id>
        <title>How to Contribute Research Results to Internet Standardization</title>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.</p><p> For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-weeb-research-to-internet-stds-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6418</doc-id>
        <title>Multiple Interfaces and Provisioning Domains Problem Statement</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>P. Seite</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>multi-homing</kw>
            <kw>MIF</kw>
            <kw>DNS</kw>
            <kw>DHCP</kw>
        </keywords>
        <abstract><p>This document describes issues encountered by a node attached to multiple provisioning domains.  This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface.  Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used.  Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism.  While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mif-problem-statement-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mif</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6418</errata-url>
        <doi>10.17487/RFC6418</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6419</doc-id>
        <title>Current Practices for Multiple-Interface Hosts</title>
        <author>
            <name>M. Wasserman</name>
        </author>
        <author>
            <name>P. Seite</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>current practices</kw>
            <kw>multi-homing</kw>
            <kw>MIF</kw>
        </keywords>
        <abstract><p>An increasing number of hosts are operating in multiple-interface environments.  This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mif-current-practices-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mif</wg_acronym>
        <doi>10.17487/RFC6419</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6420</doc-id>
        <title>PIM Multi-Topology ID (MT-ID) Join Attribute</title>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>H. Ou</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-mtid-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6420</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6421</doc-id>
        <title>Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)</title>
        <author>
            <name>D. Nelson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-radext-crypto-agility-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC6421</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6422</doc-id>
        <title>Relay-Supplied DHCP Options</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DHCPv6 Relay</kw>
            <kw>DHCPv6 option</kw>
        </keywords>
        <abstract><p>DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.</p><p> This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-relay-supplied-options-09</draft>
        <updates>
            <doc-id>RFC3315</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6422</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6423</doc-id>
        <title>Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)</title>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>J. He</name>
        </author>
        <author>
            <name>F. Huang</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-mpls-tp-gal-in-pw-01</draft>
        <updates>
            <doc-id>RFC5586</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6423</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6424</doc-id>
        <title>Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels</title>
        <author>
            <name>N. Bahadur</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>MPLS OAM</kw>
            <kw>lsp ping</kw>
            <kw>LSP-Ping</kw>
        </keywords>
        <abstract><p>This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs).  The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP.  This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-enhanced-dsmap-11</draft>
        <obsoleted-by>
            <doc-id>RFC8029</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4379</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7537</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6425</doc-id>
        <title>Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping</title>
        <author>
            <name>S. Saxena</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>S. Yasukawa</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>p2mp</kw>
        </keywords>
        <abstract><p>Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.</p><p> The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".</p><p> The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.</p><p> This document updates RFC 4379. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-p2mp-lsp-ping-18</draft>
        <updates>
            <doc-id>RFC4379</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6425</errata-url>
        <doi>10.17487/RFC6425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6426</doc-id>
        <title>MPLS On-Demand Connectivity Verification and Route Tracing</title>
        <author>
            <name>E. Gray</name>
        </author>
        <author>
            <name>N. Bahadur</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>lsp ping</kw>
            <kw>mpls tp</kw>
            <kw>mpls-tp</kw>
        </keywords>
        <abstract><p>Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs).  This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires.  This document also clarifies procedures to be used for processing the related OAM packets.  Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks.  Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-on-demand-cv-07</draft>
        <updates>
            <doc-id>RFC4379</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6426</errata-url>
        <doi>10.17487/RFC6426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6427</doc-id>
        <title>MPLS Fault Management Operations, Administration, and Maintenance (OAM)</title>
        <author>
            <name>G. Swallow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Fulignoli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Vigoureux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>mpls-oam</kw>
        </keywords>
        <abstract><p>This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths.  The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point.  This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-fault-07</draft>
        <updated-by>
            <doc-id>RFC7214</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6427</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6428</doc-id>
        <title>Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile</title>
        <author>
            <name>D. Allan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Drake</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>mpls-tp</kw>
            <kw>oam</kw>
            <kw>Operations</kw>
            <kw>Administration</kw>
            <kw>and Maintenance</kw>
            <kw>bfd</kw>
            <kw>bidirectional forwarding dectection</kw>
        </keywords>
        <abstract><p>Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).</p><p> Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section.</p><p> This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-cc-cv-rdi-06</draft>
        <updated-by>
            <doc-id>RFC7214</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6428</errata-url>
        <doi>10.17487/RFC6428</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6429</doc-id>
        <title>TCP Sender Clarification for Persist Condition</title>
        <author>
            <name>M. Bashyam</name>
        </author>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>A. Ramaiah</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>zero window probe</kw>
            <kw>denial of service (DoS)</kw>
            <kw>security vulnerability</kw>
        </keywords>
        <abstract><p>This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers").  In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition.  Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-tcpm-persist-07</draft>
        <obsoleted-by>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6429</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6430</doc-id>
        <title>Email Feedback Report Type Value: not-spam</title>
        <author>
            <name>K. Li</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>arf</kw>
            <kw>abuse reporting format</kw>
        </keywords>
        <abstract><p>This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam".  It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-not-spam-feedback-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <doi>10.17487/RFC6430</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6431</doc-id>
        <title>Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>P. Levis</name>
        </author>
        <author>
            <name>G. Bajko</name>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPv4 Address Exhaustion</kw>
            <kw>IPv4 service continuity</kw>
            <kw>IPv6</kw>
            <kw>A+P</kw>
        </keywords>
        <abstract><p>This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports.  These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-boucadair-pppext-portrange-option-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6432</doc-id>
        <title>Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses</title>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>L. Liess</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>cause code</kw>
        </keywords>
        <abstract><p>Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code.  Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems.  This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-jesske-dispatch-update3326-reason-responses-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6433</doc-id>
        <title>Requirements for a Working Group Milestones Tool</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>working group charter</kw>
            <kw>charter</kw>
        </keywords>
        <abstract><p>The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters.  This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool.  This document updates RFC 6292.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-genarea-milestones-tool-06</draft>
        <updates>
            <doc-id>RFC6292</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6433</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6434</doc-id>
        <title>IPv6 Node Requirements</title>
        <author>
            <name>E. Jankiewicz</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Internet Protocol Version 6</kw>
            <kw>Internet Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document defines requirements for IPv6 nodes.  It is expected that IPv6 will be deployed in a wide range of devices and situations.  Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-6man-node-req-bis-11</draft>
        <obsoletes>
            <doc-id>RFC4294</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8504</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6434</errata-url>
        <doi>10.17487/RFC6434</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6435</doc-id>
        <title>MPLS Transport Profile Lock Instruct and Loopback Functions</title>
        <author>
            <name>S. Boutros</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sivabalan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Aggarwal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Vigoureux</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Dai</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>oam</kw>
            <kw>operations</kw>
            <kw>administration</kw>
            <kw>and maintenance</kw>
        </keywords>
        <abstract><p>Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.</p><p> This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.</p><p> This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-tp-li-lb-08</draft>
        <updates>
            <doc-id>RFC6371</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6435</errata-url>
        <doi>10.17487/RFC6435</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6436</doc-id>
        <title>Rationale for Update to the IPv6 Flow Label Specification</title>
        <author>
            <name>S. Amante</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ECMP</kw>
            <kw>LAG</kw>
        </keywords>
        <abstract><p>Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697.  Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification.  This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-6man-flow-update-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6436</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6437</doc-id>
        <title>IPv6 Flow Label Specification</title>
        <author>
            <name>S. Amante</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>J. Rajahalme</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 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 the scope for this document.</p><p> The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-flow-3697bis-07</draft>
        <obsoletes>
            <doc-id>RFC3697</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2205</doc-id>
            <doc-id>RFC2460</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6437</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6438</doc-id>
        <title>Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ECMP</kw>
            <kw>LAG</kw>
        </keywords>
        <abstract><p>The IPv6 flow label has certain restrictions on its use.  This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-flow-ecmp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6438</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6439</doc-id>
        <title>Routing Bridges (RBridges): Appointed Forwarders</title>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>D. Eastlake</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <author>
            <name>F. Hu</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>trill</kw>
            <kw>TRansparent Interconnection of Lots of Links</kw>
        </keywords>
        <abstract><p>The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).</p><p> TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-trill-rbridge-af-05</draft>
        <obsoleted-by>
            <doc-id>RFC8139</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7180</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC6439</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6440</doc-id>
        <title>The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>Y. Wang</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>re-authentication</kw>
            <kw>handover</kw>
            <kw>LDN</kw>
            <kw>Discovery</kw>
        </keywords>
        <abstract><p>In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.</p><p> This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hokey-ldn-discovery-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <doi>10.17487/RFC6440</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6441</doc-id>
        <title>Time to Remove Filters for Previously Unallocated IPv4 /8s</title>
        <author>
            <name>L. Vegoda</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>bogons</kw>
            <kw>IPv4</kw>
            <kw>martians</kw>
            <kw>filters</kw>
        </keywords>
        <abstract><p>It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.</p><p> This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-grow-no-more-unallocated-slash8s-04</draft>
        <is-also>
            <doc-id>BCP0171</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6441</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6442</doc-id>
        <title>Location Conveyance for the Session Initiation Protocol</title>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>geographic location</kw>
            <kw>location target</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity.  The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-location-conveyance-09</draft>
        <updated-by>
            <doc-id>RFC8262</doc-id>
            <doc-id>RFC8787</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6442</errata-url>
        <doi>10.17487/RFC6442</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6443</doc-id>
        <title>Framework for Emergency Calling Using Internet Multimedia</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>The IETF has standardized various aspects of placing emergency calls.  This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ecrit-framework-13</draft>
        <updated-by>
            <doc-id>RFC7852</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC6443</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6444</doc-id>
        <title>Location Hiding: Problem Statement and Requirements</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>L. Liess</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>B. Stark</name>
        </author>
        <author>
            <name>A. Kuett</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>emergency call</kw>
            <kw>privacy</kw>
            <kw>PSAP</kw>
            <kw>Location by Reference</kw>
        </keywords>
        <abstract><p>The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.</p><p> This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ecrit-location-hiding-req-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC6444</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6445</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Koushik</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Cetin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>mib</kw>
            <kw>frr</kw>
            <kw>MPLS-FRR-GENERAL-STD-MIB</kw>
            <kw>MPLS-FRR-ONE2ONE-STD-MIB</kw>
            <kw>MPLS-FRR-FACILITY-STD-MIB</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community.  In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE).  The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-fastreroute-mib-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6445</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6446</doc-id>
        <title>Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control</title>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>K. Kiss</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>events</kw>
            <kw>rate control</kw>
        </keywords>
        <abstract><p>This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications.  These mechanisms can be applied in subscriptions to all SIP event packages.  This document updates RFC 3265. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-event-rate-control-09</draft>
        <updates>
            <doc-id>RFC3265</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC6446</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6447</doc-id>
        <title>Filtering Location Notifications in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>geopriv</kw>
            <kw>location</kw>
        </keywords>
        <abstract><p>This document describes filters that limit asynchronous location notifications to compelling events.  These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package.  The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-loc-filters-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6447</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6448</doc-id>
        <title>The Unencrypted Form of Kerberos 5 KRB-CRED Message</title>
        <author>
            <name>R. Yount</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>credential</kw>
        </keywords>
        <abstract><p>The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications.  When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable.  This document describes the unencrypted form of the KRB-CRED message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-clear-text-cred-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6448</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6449</doc-id>
        <title>Complaint Feedback Loop Operational Recommendations</title>
        <author>
            <name>J. Falk</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>MAAWG</kw>
            <kw>ARF</kw>
            <kw>MARF</kw>
            <kw>feedback loop</kw>
            <kw>spam reporting</kw>
        </keywords>
        <abstract><p>Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.</p><p> This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-jdfalk-maawg-cfblbcp-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6449</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6450</doc-id>
        <title>Multicast Ping Protocol</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>ssm</kw>
            <kw>asm</kw>
            <kw>ssmping</kw>
            <kw>asmping</kw>
        </keywords>
        <abstract><p>The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM).  It can also be used to obtain additional multicast-related information, such as multicast tree setup time.  This protocol is based on an implementation of tools called "ssmping" and "asmping". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mboned-ssmping-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC6450</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6451</doc-id>
        <title>Location-to-Service Translation (LoST) Protocol Extensions</title>
        <author>
            <name>A. Forte</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>location-based services</kw>
            <kw>location</kw>
            <kw>GPS</kw>
            <kw>point of interest</kw>
        </keywords>
        <abstract><p>An important class of location-based services answers the question, "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces.  Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions.  This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by".  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-forte-lost-extensions-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6452</doc-id>
        <title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0</title>
        <author>
            <name>P. Faltstrom</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Hoffman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>IDN</kw>
        </keywords>
        <abstract><p>This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released.  The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-faltstrom-5892bis-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC6452</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6453</doc-id>
        <title>A URN Namespace for the Open Grid Forum (OGF)</title>
        <author>
            <name>F. Dijkstra</name>
        </author>
        <author>
            <name>R. Hughes-Jones</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>identifier</kw>
        </keywords>
        <abstract><p>This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-dijkstra-urn-ogf-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6453</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6454</doc-id>
        <title>The Web Origin Concept</title>
        <author>
            <name>A. Barth</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>same-origin</kw>
            <kw>policy</kw>
            <kw>security</kw>
            <kw>cross-origin</kw>
        </keywords>
        <abstract><p>This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string.  It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-websec-origin-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>websec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6454</errata-url>
        <doi>10.17487/RFC6454</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6455</doc-id>
        <title>The WebSocket Protocol</title>
        <author>
            <name>I. Fette</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>HyBi Working Group</kw>
            <kw>HYBI</kw>
            <kw>websocket</kw>
        </keywords>
        <abstract><p>The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code.  The security model used for this is the origin-based security model commonly used by web browsers.  The protocol consists of an opening handshake followed by basic message framing, layered over TCP.  The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s and long polling). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hybi-thewebsocketprotocol-17</draft>
        <updated-by>
            <doc-id>RFC7936</doc-id>
            <doc-id>RFC8307</doc-id>
            <doc-id>RFC8441</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>hybi</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6455</errata-url>
        <doi>10.17487/RFC6455</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6456</doc-id>
        <title>Multi-Segment Pseudowires in Passive Optical Networks</title>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>R. Zheng</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>November</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>PSN</kw>
            <kw>PON</kw>
            <kw>G-PON</kw>
            <kw>XG-PON</kw>
            <kw>OMCI</kw>
        </keywords>
        <abstract><p>This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN).</p><p> PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.</p><p> This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.</p><p> This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-li-pwe3-ms-pw-pon-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6457</doc-id>
        <title>PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering</title>
        <author>
            <name>T. Takeda</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>PCEP</kw>
            <kw>inter-layer</kw>
            <kw>traffic engineering</kw>
            <kw>MPLS</kw>
            <kw>GMPLS</kw>
            <kw>VNT</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS).</p><p> MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.</p><p> Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery".</p><p> This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pce-inter-layer-req-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC6457</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6458</doc-id>
        <title>Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>K. Poon</name>
        </author>
        <author>
            <name>P. Lei</name>
        </author>
        <author>
            <name>V. Yasevich</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>115</page-count>
        <abstract><p>This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API.  The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-tsvwg-sctpsocket-32</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6458</errata-url>
        <doi>10.17487/RFC6458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6459</doc-id>
        <title>IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Soininen</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>G. Bajko</name>
        </author>
        <author>
            <name>K. Iisakkila</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Transition</kw>
            <kw>Migration</kw>
        </keywords>
        <abstract><p>The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed.  Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6.  This document describes the support for IPv6 in 3GPP network architectures.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-3gpp-eps-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6460</doc-id>
        <title>Suite B Profile for Transport Layer Security (TLS)</title>
        <author>
            <name>M. Salter</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>cryptographic algorithm policy</kw>
        </keywords>
        <abstract><p>The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications.  This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-salter-rfc5430bis-01</draft>
        <obsoletes>
            <doc-id>RFC5430</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6460</errata-url>
        <doi>10.17487/RFC6460</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6461</doc-id>
        <title>Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements</title>
        <author>
            <name>S. Channabasappa</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>registry</kw>
            <kw>registry provisioning</kw>
            <kw>registrar</kw>
            <kw>destination group</kw>
            <kw>route group</kw>
        </keywords>
        <abstract><p>This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing.  Specifically, this document focuses on the provisioning of one such element termed the "registry".  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-drinks-usecases-requirements-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>drinks</wg_acronym>
        <doi>10.17487/RFC6461</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6462</doc-id>
        <title>Report from the Internet Privacy Workshop</title>
        <author>
            <name>A. Cooper</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-privacy-workshop-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6462</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6463</doc-id>
        <title>Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>X. Cui</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6.  The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor.  The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netext-redirect-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6463</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6464</doc-id>
        <title>A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication</title>
        <author>
            <name>J. Lennox</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Ivov</name>
        </author>
        <author>
            <name>E. Marocco</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ssrc-audio-level</kw>
            <kw>ssrc</kw>
            <kw>speech</kw>
            <kw>sound</kw>
            <kw>energy</kw>
            <kw>conference</kw>
            <kw>bridge</kw>
        </keywords>
        <abstract><p>This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet.  In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtext-client-to-mixer-audio-level-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC6464</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6465</doc-id>
        <title>A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication</title>
        <author>
            <name>E. Ivov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Marocco</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Lennox</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>csrc-audio-level</kw>
            <kw>csrc</kw>
            <kw>speech</kw>
            <kw>sound</kw>
            <kw>energy</kw>
            <kw>conference</kw>
            <kw>bridge</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants.  Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtext-mixer-to-client-audio-level-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC6465</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6466</doc-id>
        <title>IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)</title>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>t.38 media</kw>
        </keywords>
        <abstract><p>This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP).  This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-salgueiro-mmusic-image-iana-registration-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6466</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6467</doc-id>
        <title>Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>IKE</kw>
            <kw>mutual authentication</kw>
            <kw>credentials</kw>
            <kw>VPN gateway</kw>
        </keywords>
        <abstract><p>This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods.  Multiple methods are already specified in other documents, and this document does not add any new one.  This document specifies a way to agree on which method is to be used in the current connection.  This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.</p></abstract>
        <draft>draft-kivinen-ipsecme-secure-password-framework-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6467</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6468</doc-id>
        <title>Sieve Notification Mechanism: SIP MESSAGE</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>K. Li</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Sieve</kw>
            <kw>SIP</kw>
            <kw>notification</kw>
        </keywords>
        <abstract><p>This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-notify-sip-message-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6468</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6469</doc-id>
        <title>RTP Payload Format for DV (IEC 61834) Video</title>
        <author>
            <name>K. Kobayashi</name>
        </author>
        <author>
            <name>K. Mishima</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DV/RTP</kw>
            <kw>real-time transport protocol</kw>
        </keywords>
        <abstract><p>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).  This document obsoletes RFC 3189. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-payload-rfc3189bis-03</draft>
        <obsoletes>
            <doc-id>RFC3189</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC6469</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6470</doc-id>
        <title>Network Configuration Protocol (NETCONF) Base Notifications</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>XML</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores.  However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications.  Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server.  This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-system-notifications-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6470</errata-url>
        <doi>10.17487/RFC6470</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6471</doc-id>
        <title>Overview of Best Email DNS-Based List (DNSBL) Operational Practices</title>
        <author>
            <name>C. Lewis</name>
        </author>
        <author>
            <name>M. Sergeant</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>DNSBL policy</kw>
        </keywords>
        <abstract><p>The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering.  This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties.  It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-asrg-bcp-blacklists-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6471</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6472</doc-id>
        <title>Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>K. Sriram</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BGPv4</kw>
            <kw>Operator</kw>
            <kw>RPKI</kw>
            <kw>Aggregation</kw>
            <kw>Route Origin</kw>
        </keywords>
        <abstract><p>This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4.  This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear.  This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-idr-deprecate-as-sets-06</draft>
        <obsoleted-by>
            <doc-id>RFC9774</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>BCP0172</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC6472</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6473</doc-id>
        <title>vCard KIND:application</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>vCard</kw>
        </keywords>
        <abstract><p>This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-kind-app-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <doi>10.17487/RFC6473</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6474</doc-id>
        <title>vCard Format Extensions: Place of Birth, Place and Date of Death</title>
        <author>
            <name>K. Li</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>December</month>
            <year>2011</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>contacts</kw>
            <kw>address-book</kw>
            <kw>personal-information</kw>
        </keywords>
        <abstract><p>The base vCard 4.0 specification defines a large number of properties, including date of birth.  This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-birth-death-extensions-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6474</errata-url>
        <doi>10.17487/RFC6474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6475</doc-id>
        <title>Proxy Mobile IPv6 Management Information Base</title>
        <author>
            <name>G. Keeni</name>
        </author>
        <author>
            <name>K. Koide</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
        </keywords>
        <abstract><p>This memo defines a portion of the Proxy Mobile IPv6 Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netlmm-pmipv6-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6475</errata-url>
        <doi>10.17487/RFC6475</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6476</doc-id>
        <title>Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>P. Gutmann</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>authenticated data</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type.  This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gutmann-cms-hmac-enc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6476</errata-url>
        <doi>10.17487/RFC6476</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6477</doc-id>
        <title>Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>G. Lunt</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks.  The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123.  This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service.  In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-melnikov-mmhs-header-fields-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6477</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6478</doc-id>
        <title>Pseudowire Status for Static Pseudowires</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>G. Heron</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh).  Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE.  The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs.  This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-static-pw-status-10</draft>
        <updates>
            <doc-id>RFC5885</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6478</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6479</doc-id>
        <title>IPsec Anti-Replay Algorithm without Bit Shifting</title>
        <author>
            <name>X. Zhang</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP).  The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-zhang-ipsecme-anti-replay-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6479</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6480</doc-id>
        <title>An Infrastructure to Support Secure Internet Routing</title>
        <author>
            <name>M. Lepinski</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>BGP</kw>
            <kw>ROA</kw>
        </keywords>
        <abstract><p>This document describes an architecture for an infrastructure to support improved security of Internet routing.  The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security.  As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space.  Such verifiable authorizations could be used, for example, to more securely construct BGP route filters.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sidr-arch-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6480</errata-url>
        <doi>10.17487/RFC6480</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6481</doc-id>
        <title>A Profile for Resource Certificate Repository Structure</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>R. Loomans</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>rpki</kw>
            <kw>Resource Public Key Infrastructure</kw>
        </keywords>
        <abstract><p>This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository.  Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects.  This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-repos-struct-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6481</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6482</doc-id>
        <title>A Profile for Route Origin Authorizations (ROAs)</title>
        <author>
            <name>M. Lepinski</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>D. Kong</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>This document defines a standard profile for Route Origin Authorizations (ROAs).  A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-roa-format-12</draft>
        <obsoleted-by>
            <doc-id>RFC9582</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6482</errata-url>
        <doi>10.17487/RFC6482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6483</doc-id>
        <title>Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>rpki</kw>
            <kw>bgp</kw>
            <kw>Resource Public Key Infrastructure</kw>
        </keywords>
        <abstract><p>This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-sidr-roa-validation-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6483</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6484</doc-id>
        <title>Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>D. Kong</name>
        </author>
        <author>
            <name>K. Seo</name>
        </author>
        <author>
            <name>R. Watro</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Certification Practice Statement</kw>
            <kw>CPS</kw>
        </keywords>
        <abstract><p>This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings.  Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution.  These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-sidr-cp-17</draft>
        <is-also>
            <doc-id>BCP0173</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6484</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6485</doc-id>
        <title>The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-rpki-algs-05</draft>
        <obsoleted-by>
            <doc-id>RFC7935</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6485</errata-url>
        <doi>10.17487/RFC6485</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6486</doc-id>
        <title>Manifests for the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>M. Lepinski</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI).  A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository.  For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content.  Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository.  Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-rpki-manifests-16</draft>
        <obsoleted-by>
            <doc-id>RFC9286</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6486</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6487</doc-id>
        <title>A Profile for X.509 PKIX Resource Certificates</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>R. Loomans</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>rpki</kw>
            <kw>Resource Public Key Infrastructure</kw>
            <kw>Internet Number Resources</kw>
            <kw>INR</kw>
        </keywords>
        <abstract><p>This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs).  The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate.  This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI).  This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-res-certs-22</draft>
        <updated-by>
            <doc-id>RFC7318</doc-id>
            <doc-id>RFC8209</doc-id>
            <doc-id>RFC9829</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6487</errata-url>
        <doi>10.17487/RFC6487</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6488</doc-id>
        <title>Signed Object Template for the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>M. Lepinski</name>
        </author>
        <author>
            <name>A. Chi</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ROA</kw>
            <kw>manifest</kw>
            <kw>GhostBusters</kw>
        </keywords>
        <abstract><p>This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI).  These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-signed-object-04</draft>
        <updated-by>
            <doc-id>RFC9589</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6488</errata-url>
        <doi>10.17487/RFC6488</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6489</doc-id>
        <title>Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>RPKI</kw>
        </keywords>
        <abstract><p>This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair.  This document also notes the implications of this key rollover procedure for relying parties (RPs).  In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-sidr-keyroll-08</draft>
        <is-also>
            <doc-id>BCP0174</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6489</errata-url>
        <doi>10.17487/RFC6489</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6490</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Trust Anchor Locator</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>tal</kw>
        </keywords>
        <abstract><p>This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-ta-07</draft>
        <obsoleted-by>
            <doc-id>RFC7730</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6490</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6491</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Objects Issued by IANA</title>
        <author>
            <name>T. Manderson</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>sidr</kw>
            <kw>rpki</kw>
            <kw>iana</kw>
            <kw>as0</kw>
            <kw>as 0</kw>
            <kw>roa</kw>
        </keywords>
        <abstract><p>This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-iana-objects-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6491</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6492</doc-id>
        <title>A Protocol for Provisioning Resource Certificates</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>R. Loomans</name>
        </author>
        <author>
            <name>B. Ellacott</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>RPKI</kw>
        </keywords>
        <abstract><p>This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties.  The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports.  This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-rescerts-provisioning-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6492</errata-url>
        <doi>10.17487/RFC6492</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6493</doc-id>
        <title>The Resource Public Key Infrastructure (RPKI) Ghostbusters Record</title>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>Resource Certificate</kw>
            <kw>Human Contact</kw>
            <kw>vCard</kw>
        </keywords>
        <abstract><p>In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc.  This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate.  The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]</p></abstract>
        <draft>draft-ietf-sidr-ghostbusters-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6493</errata-url>
        <doi>10.17487/RFC6493</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6494</doc-id>
        <title>Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)</title>
        <author>
            <name>R. Gagliano</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>A. Kukec</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>ND</kw>
        </keywords>
        <abstract><p>SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization.  This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-csi-send-cert-10</draft>
        <updates>
            <doc-id>RFC3971</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>csi</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6494</errata-url>
        <doi>10.17487/RFC6494</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6495</doc-id>
        <title>Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields</title>
        <author>
            <name>R. Gagliano</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>A. Kukec</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option.  This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-csi-send-name-type-registry-06</draft>
        <updates>
            <doc-id>RFC3971</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>csi</wg_acronym>
        <doi>10.17487/RFC6495</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6496</doc-id>
        <title>Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>M. Bonola</name>
        </author>
        <author>
            <name>A. Garcia-Martinez</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>SPND</kw>
            <kw>CGA</kw>
            <kw>Mobile IPv6</kw>
            <kw>MIPv6</kw>
            <kw>Proxy Mobile IPv6</kw>
            <kw>PMIPv6</kw>
        </keywords>
        <abstract><p>SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats.  As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message.  This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND.  This document extends the current SEND specification in order to secure Proxy ND operation.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-csi-proxy-send-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>csi</wg_acronym>
        <doi>10.17487/RFC6496</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6497</doc-id>
        <title>BCP 47 Extension T - Transformed Content</title>
        <author>
            <name>M. Davis</name>
        </author>
        <author>
            <name>A. Phillips</name>
        </author>
        <author>
            <name>Y. Umaoka</name>
        </author>
        <author>
            <name>C. Falk</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>locale</kw>
        </keywords>
        <abstract><p>This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source.  It also provides for additional information used for identification.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-davis-t-langtag-ext-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6497</errata-url>
        <doi>10.17487/RFC6497</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6498</doc-id>
        <title>Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package</title>
        <author>
            <name>J. Stone</name>
        </author>
        <author>
            <name>R. Kumar</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction).  Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec.  In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-stone-mgcp-vbd-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6498</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6499</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6500</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6501</doc-id>
        <title>Conference Information Data Model for Centralized Conferencing (XCON)</title>
        <author>
            <name>O. Novo</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>D. Morgan</name>
        </author>
        <author>
            <name>J. Urpalainen</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
        </keywords>
        <abstract><p>RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus.  The state of a conference is represented by a conference object.  This document defines an XML- based conference information data model to be used for conference objects.  A conference information data model is designed to convey information about the conference and about participation in the conference.  The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xcon-common-data-model-32</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC6501</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6502</doc-id>
        <title>Conference Event Package Data Format Extension for Centralized Conferencing (XCON)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>S. Srinivasan</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>J. Urpalainen</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies the notification mechanism for XCON (centralized conferencing).  This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state.  Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xcon-event-package-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC6502</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6503</doc-id>
        <title>Centralized Conferencing Manipulation Protocol</title>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>C. Boulton</name>
        </author>
        <author>
            <name>S. Romano</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>119</page-count>
        <keywords>
            <kw>conference user</kw>
            <kw>ad hoc conference</kw>
            <kw>sidebar conference</kw>
            <kw>scheduled conference</kw>
        </keywords>
        <abstract><p>The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference.  CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details.  CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xcon-ccmp-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6503</errata-url>
        <doi>10.17487/RFC6503</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6504</doc-id>
        <title>Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples</title>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>L. Miniero</name>
        </author>
        <author>
            <name>R. Presta</name>
        </author>
        <author>
            <name>S P. Romano</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>78</page-count>
        <abstract><p>This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597).  The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503).  The objective is to provide detailed examples for reference by both protocol researchers and developers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-xcon-examples-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xcon</wg_acronym>
        <doi>10.17487/RFC6504</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6505</doc-id>
        <title>A Mixer Control Package for the Media Control Channel Framework</title>
        <author>
            <name>S. McGlashan</name>
        </author>
        <author>
            <name>T. Melanchuk</name>
        </author>
        <author>
            <name>C. Boulton</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>89</page-count>
        <keywords>
            <kw>conference mixer</kw>
        </keywords>
        <abstract><p>This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections.  The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications.  The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mediactrl-mixer-control-package-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6505</errata-url>
        <doi>10.17487/RFC6505</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6506</doc-id>
        <title>Supporting Authentication Trailer for OSPFv3</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Routing security</kw>
        </keywords>
        <abstract><p>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets.  This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)).  In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used.  This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-auth-trailer-ospfv3-11</draft>
        <obsoleted-by>
            <doc-id>RFC7166</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6506</errata-url>
        <doi>10.17487/RFC6506</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6507</doc-id>
        <title>Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)</title>
        <author>
            <name>M. Groves</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Many signature schemes currently in use rely on certificates for authentication of identity.  In Identity-based cryptography, this adds unnecessary overhead and administration.  The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless.  This scheme has the additional advantages of low bandwidth and low computational requirements.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-groves-eccsi-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6507</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6508</doc-id>
        <title>Sakai-Kasahara Key Encryption (SAKKE)</title>
        <author>
            <name>M. Groves</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described.  This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-groves-sakke-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6508</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6509</doc-id>
        <title>MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)</title>
        <author>
            <name>M. Groves</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication.  MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-groves-mikey-sakke-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6509</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6510</doc-id>
        <title>Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes.  These attributes may be carried in both Path and Resv messages.  This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats.  This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-attribute-bnf-02</draft>
        <updates>
            <doc-id>RFC4875</doc-id>
            <doc-id>RFC5420</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6510</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6511</doc-id>
        <title>Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths</title>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism.  This document defines protocol mechanisms to address this requirement.  The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6511</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6512</doc-id>
        <title>Using Multipoint LDP When the Backbone Has No Route to the Root</title>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>M. Napierala</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node".  Intermediate nodes are expected to be able to look up that address in their routing tables.  However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core.  This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core.  In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-mldp-recurs-fec-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6512</errata-url>
        <doi>10.17487/RFC6512</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6513</doc-id>
        <title>Multicast in MPLS/BGP IP VPNs</title>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Aggarwal</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
        </keywords>
        <abstract><p>In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider.  These protocols and procedures are specified in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-2547bis-mcast-10</draft>
        <updated-by>
            <doc-id>RFC7582</doc-id>
            <doc-id>RFC7900</doc-id>
            <doc-id>RFC7988</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6513</errata-url>
        <doi>10.17487/RFC6513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6514</doc-id>
        <title>BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs</title>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>T. Morin</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <abstract><p>This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-2547bis-mcast-bgp-08</draft>
        <updated-by>
            <doc-id>RFC6515</doc-id>
            <doc-id>RFC6625</doc-id>
            <doc-id>RFC7385</doc-id>
            <doc-id>RFC7441</doc-id>
            <doc-id>RFC7582</doc-id>
            <doc-id>RFC7899</doc-id>
            <doc-id>RFC7900</doc-id>
            <doc-id>RFC7902</doc-id>
            <doc-id>RFC7988</doc-id>
            <doc-id>RFC8534</doc-id>
            <doc-id>RFC9081</doc-id>
            <doc-id>RFC9573</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6514</errata-url>
        <doi>10.17487/RFC6514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6515</doc-id>
        <title>IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN</title>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>mvpn</kw>
            <kw>mcast-vpn</kw>
            <kw>multicast-vpn</kw>
        </keywords>
        <abstract><p>To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes.  These routes encode addresses from the customer's address space, as well as addresses from the provider's address space.  These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same.  These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses.  However, there is no field that explicitly specifies the address family of the provider addresses.  To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field.  Specific cases are explained in detail.  This document updates RFC 6514. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-mvpn-infra-addrs-05</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6515</errata-url>
        <doi>10.17487/RFC6515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6516</doc-id>
        <title>IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages</title>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Wijnands</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers.  It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network.  This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-mvpn-spmsi-joins-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC6516</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6517</doc-id>
        <title>Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution</title>
        <author>
            <name>T. Morin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Niven-Jenkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Kamite</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>vpn</kw>
            <kw>multicast</kw>
            <kw>l3vpn</kw>
            <kw>bgp</kw>
            <kw>pim</kw>
            <kw>p2mp</kw>
            <kw>ldp</kw>
            <kw>rsvp-te</kw>
        </keywords>
        <abstract><p>More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.</p><p> To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-l3vpn-mvpn-considerations-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC6517</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6518</doc-id>
        <title>Keying and Authentication for Routing Protocols (KARP) Design Guidelines</title>
        <author>
            <name>G. Lebovitz</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>MAC</kw>
            <kw>hash</kw>
            <kw>security</kw>
            <kw>securing</kw>
            <kw>secure</kw>
            <kw>authorization</kw>
            <kw>protection</kw>
            <kw>harden</kw>
            <kw>hardening</kw>
            <kw>infrastructure</kw>
            <kw>router</kw>
            <kw>crypto</kw>
            <kw>cryptography</kw>
            <kw>cryptographic</kw>
            <kw>roadmap</kw>
            <kw>guide</kw>
            <kw>guideline</kw>
            <kw>message</kw>
            <kw>framework</kw>
            <kw>key</kw>
            <kw>keys</kw>
            <kw>management</kw>
            <kw>protocol</kw>
            <kw>KMP</kw>
            <kw>key management protocol,</kw>
        </keywords>
        <abstract><p>This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols.  In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-karp-design-guide-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>karp</wg_acronym>
        <doi>10.17487/RFC6518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6519</doc-id>
        <title>RADIUS Extensions for Dual-Stack Lite</title>
        <author>
            <name>R. Maglione</name>
        </author>
        <author>
            <name>A. Durand</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>tunnel</kw>
            <kw>attribute</kw>
        </keywords>
        <abstract><p>Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix.  Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element.  In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP).  This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option.  This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-dslite-radius-ext-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6519</errata-url>
        <doi>10.17487/RFC6519</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6520</doc-id>
        <title>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension</title>
        <author>
            <name>R. Seggelmann</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>M. Williams</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>tls/dtls</kw>
        </keywords>
        <abstract><p>This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.</p><p> The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tls-dtls-heartbeat-04</draft>
        <updated-by>
            <doc-id>RFC8447</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6520</errata-url>
        <doi>10.17487/RFC6520</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6521</doc-id>
        <title>Home Agent-Assisted Route Optimization between Mobile IPv4 Networks</title>
        <author>
            <name>A. Makela</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>mobile router</kw>
            <kw>mobile network prefix</kw>
            <kw>correspondent router</kw>
        </keywords>
        <abstract><p>This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol.  The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity.  The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mip4-nemo-haaro-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC6521</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6522</doc-id>
        <title>The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages</title>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>Multipurpose Internet Mail Extensions</kw>
        </keywords>
        <abstract><p>The multipart/report Multipurpose Internet Mail Extensions (MIME) media 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 media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.</p><p> This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-appsawg-rfc3462bis-04</draft>
        <obsoletes>
            <doc-id>RFC3462</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC6533</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0073</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC6522</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6523</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6524</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6525</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Stream Reconfiguration</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>P. Lei</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
        </keywords>
        <abstract><p>Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream.  The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed.  Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows.  Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero".  This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-strrst-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6525</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6526</doc-id>
        <title>IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream</title>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>A. Johnson</name>
        </author>
        <author>
            <name>G. Muenz</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol).</p><p> When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-export-per-sctp-stream-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC6526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6527</doc-id>
        <title>Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)</title>
        <author>
            <name>K. Tata</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP).  In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798.  This memo obsoletes RFC 2787. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vrrp-unified-mib-10</draft>
        <obsoletes>
            <doc-id>RFC2787</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6527</errata-url>
        <doi>10.17487/RFC6527</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6528</doc-id>
        <title>Defending against Sequence Number Attacks</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TCP security</kw>
            <kw>TCP Sequence Numbers</kw>
            <kw>Sequence Number Randomization</kw>
            <kw>obfuscation</kw>
            <kw>TCP vulnerabilities</kw>
        </keywords>
        <abstract><p>This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced.  This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-rfc1948bis-02</draft>
        <obsoletes>
            <doc-id>RFC1948</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0793</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6528</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6529</doc-id>
        <title>Host/Host Protocol for the ARPA Network</title>
        <author>
            <name>A. McKenzie</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971.  It describes a protocol used to manage communication between processes residing on independent Hosts.  It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface.  It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983.  It is offered as an RFC at this late date to help complete the historical record available through the RFC series.  This document is not an Internet Standards Track specification; it is published for the historical record.</p></abstract>
        <draft>draft-mckenzie-arpanet-host-host-protocol-01</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6529</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6530</doc-id>
        <title>Overview and Framework for Internationalized Email</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>Y. Ko</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>Email I18n</kw>
            <kw>Internationalization</kw>
            <kw>SMTPUTF8</kw>
        </keywords>
        <abstract><p>Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses.  This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses.  These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data.  The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.  This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-eai-frmwrk-4952bis-12</draft>
        <obsoletes>
            <doc-id>RFC4952</doc-id>
            <doc-id>RFC5504</doc-id>
            <doc-id>RFC5825</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC6530</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6531</doc-id>
        <title>SMTP Extension for Internationalized Email</title>
        <author>
            <name>J. Yao</name>
        </author>
        <author>
            <name>W. Mao</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>Email I18n</kw>
            <kw>Internationalization</kw>
            <kw>SMTPUTF8</kw>
        </keywords>
        <abstract><p>This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-eai-rfc5336bis-16</draft>
        <obsoletes>
            <doc-id>RFC5336</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6531</errata-url>
        <doi>10.17487/RFC6531</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6532</doc-id>
        <title>Internationalized Email Headers</title>
        <author>
            <name>A. Yang</name>
        </author>
        <author>
            <name>S. Steele</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.</p><p> This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-eai-rfc5335bis-13</draft>
        <obsoletes>
            <doc-id>RFC5335</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2045</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6532</errata-url>
        <doi>10.17487/RFC6532</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6533</doc-id>
        <title>Internationalized Delivery Status and Disposition Notifications</title>
        <author>
            <name>T. Hansen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>dsn</kw>
        </keywords>
        <abstract><p>Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.</p><p> This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-eai-rfc5337bis-dsn-06</draft>
        <obsoletes>
            <doc-id>RFC5337</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3461</doc-id>
            <doc-id>RFC3464</doc-id>
            <doc-id>RFC3798</doc-id>
            <doc-id>RFC6522</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC6533</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6534</doc-id>
        <title>Loss Episode Metrics for IP Performance Metrics (IPPM)</title>
        <author>
            <name>N. Duffield</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>J. Sommers</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
        </keywords>
        <abstract><p>The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts.  However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets).  This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-loss-episode-metrics-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6534</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6535</doc-id>
        <title>Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)</title>
        <author>
            <name>B. Huang</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>NAT46</kw>
            <kw>DNS</kw>
            <kw>DNS46</kw>
            <kw>translation</kw>
            <kw>IPv4</kw>
            <kw>applications</kw>
            <kw>IPv6</kw>
            <kw>ENR</kw>
        </keywords>
        <abstract><p>Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers.  The host on which applications are running may be connected to IPv6-only or dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-behave-v4v6-bih-09</draft>
        <obsoletes>
            <doc-id>RFC2767</doc-id>
            <doc-id>RFC3338</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6535</errata-url>
        <doi>10.17487/RFC6535</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6536</doc-id>
        <title>Network Configuration Protocol (NETCONF) Access Control Model</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>YANG</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.  There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content.  This document defines such an access control model. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netconf-access-control-07</draft>
        <obsoleted-by>
            <doc-id>RFC8341</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6536</errata-url>
        <doi>10.17487/RFC6536</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6537</doc-id>
        <title>Host Identity Protocol Distributed Hash Table Interface</title>
        <author>
            <name>J. Ahrenholz</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>Host Identity Protocol</kw>
            <kw>DHT</kw>
            <kw>DIstributed Hash Table</kw>
            <kw>HIT</kw>
            <kw>Host Identity Tag</kw>
            <kw>resolution</kw>
            <kw>service</kw>
        </keywords>
        <abstract><p>This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-hiprg-dht-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6537</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6538</doc-id>
        <title>The Host Identity Protocol (HIP) Experiment Report</title>
        <author>
            <name>T. Henderson</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>ID/locator split</kw>
            <kw>IPsec</kw>
            <kw>Research</kw>
        </keywords>
        <abstract><p>This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group.  The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications.  The perspective of a network operator, as well as a list of HIP experiments, are presented as well.  Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-irtf-hip-experiment-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6538</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6539</doc-id>
        <title>IBAKE: Identity-Based Authenticated Key Exchange</title>
        <author>
            <name>V. Cakulev</name>
        </author>
        <author>
            <name>G. Sundaram</name>
        </author>
        <author>
            <name>I. Broustis</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ibe</kw>
            <kw>identity based encryption</kw>
        </keywords>
        <abstract><p>Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management.  The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility.  However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences.  Another observed deficiency is a lack of mutual authentication of communicating parties.  This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol.  IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-cakulev-ibake-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6539</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6540</doc-id>
        <title>IPv6 Support Required for All IP-Capable Nodes</title>
        <author>
            <name>W. George</name>
        </author>
        <author>
            <name>C. Donley</name>
        </author>
        <author>
            <name>C. Liljenstolpe</name>
        </author>
        <author>
            <name>L. Howard</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPv4</kw>
            <kw>requirement</kw>
        </keywords>
        <abstract><p>Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional.  It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-intarea-ipv6-required-02</draft>
        <is-also>
            <doc-id>BCP0177</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC6540</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6541</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Authentication</kw>
            <kw>Reputation</kw>
        </keywords>
        <abstract><p>This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-kucherawy-dkim-atps-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6541</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6542</doc-id>
        <title>Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility</title>
        <author>
            <name>S. Emery</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121).  This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961.  In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-gss-cb-hash-agility-10</draft>
        <updates>
            <doc-id>RFC4121</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6542</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6543</doc-id>
        <title>Reserved IPv6 Interface Identifier for Proxy Mobile IPv6</title>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes.  This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another.  In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required.  This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose.  This document also updates RFC 5213. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gundavelli-v6ops-pmipv6-address-reservations-06</draft>
        <updates>
            <doc-id>RFC5213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6544</doc-id>
        <title>TCP Candidates with Interactive Connectivity Establishment (ICE)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>B. B. Lowekamp</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>ICE</kw>
            <kw>TCP</kw>
            <kw>NAT</kw>
            <kw>NAT traversal</kw>
        </keywords>
        <abstract><p>Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation.  ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN).  ICE provides a general framework for describing candidates but only defines UDP-based media streams.  This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mmusic-ice-tcp-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6544</errata-url>
        <doi>10.17487/RFC6544</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6545</doc-id>
        <title>Real-time Inter-network Defense (RID)</title>
        <author>
            <name>K. Moriarty</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>incident response</kw>
            <kw>incident coordination</kw>
            <kw>incident handling</kw>
            <kw>incident communication</kw>
        </keywords>
        <abstract><p>Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.  Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack.  Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution.  Combining these capabilities in a communication system provides a way to achieve higher security levels on networks.  Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.  This document obsoletes RFC 6045. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mile-rfc6045-bis-11</draft>
        <obsoletes>
            <doc-id>RFC6045</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6545</errata-url>
        <doi>10.17487/RFC6545</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6546</doc-id>
        <title>Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Coordinated Incident Response</kw>
            <kw>CSIRT</kw>
            <kw>Incident Object Description Exchange Format</kw>
            <kw>IODEF</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises.  This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mile-rfc6046-bis-09</draft>
        <obsoletes>
            <doc-id>RFC6046</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6546</errata-url>
        <doi>10.17487/RFC6546</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6547</doc-id>
        <title>RFC 3627 to Historic Status</title>
        <author>
            <name>W. George</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>/127</kw>
            <kw>point-to-point address</kw>
            <kw>inter-router links</kw>
        </keywords>
        <abstract><p>This document moves "Use of /127 Prefix Length Between Routers Considered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter- Router Links" (RFC 6164).  A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict.  This document links the two RFCs so that the IETF's updated guidance on this topic is clearer.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-6man-3627-historic-01</draft>
        <obsoletes>
            <doc-id>RFC3627</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC6164</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6547</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6548</doc-id>
        <title>Independent Submission Editor Model</title>
        <author>
            <name>N. Brownlee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Independent Stream Editor</kw>
        </keywords>
        <abstract><p>This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE).  The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver.  The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE).  The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-ise-model-07</draft>
        <obsoletes>
            <doc-id>RFC5620</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8730</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6548</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6549</doc-id>
        <title>OSPFv2 Multi-Instance Extensions</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>S. Mirtorabi</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Instance ID</kw>
        </keywords>
        <abstract><p>OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.</p><p> This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.</p><p> This document updates RFC 2328. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-multi-instance-09</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6549</errata-url>
        <doi>10.17487/RFC6549</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6550</doc-id>
        <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
        <author>
            <name>T. Winter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>R. Kelsey</name>
        </author>
        <author>
            <name>P. Levis</name>
        </author>
        <author>
            <name>K. Pister</name>
        </author>
        <author>
            <name>R. Struik</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>R. Alexander</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>157</page-count>
        <keywords>
            <kw>WSN for Wireless Sensor Network</kw>
            <kw>L3 Mesh for Layer 3 Mesh Network</kw>
            <kw>Routing Protocol</kw>
            <kw>Subnet Routing</kw>
            <kw>Distance Vector</kw>
            <kw>Objective Function</kw>
            <kw>DAG for Directed Acyclic Graph</kw>
        </keywords>
        <abstract><p>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-roll-rpl-19</draft>
        <updated-by>
            <doc-id>RFC9008</doc-id>
            <doc-id>RFC9010</doc-id>
            <doc-id>RFC9685</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6550</errata-url>
        <doi>10.17487/RFC6550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6551</doc-id>
        <title>Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks</title>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kim</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Pister</name>
        </author>
        <author>
            <name>N. Dejean</name>
        </author>
        <author>
            <name>D. Barthel</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>RPL</kw>
            <kw>ROLL</kw>
            <kw>LLN</kw>
            <kw>Constrained based routing,</kw>
        </keywords>
        <abstract><p>Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints.  By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-roll-routing-metrics-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6551</errata-url>
        <doi>10.17487/RFC6551</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6552</doc-id>
        <title>Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>WSN for Wireless Sensor Network</kw>
            <kw>L3 Mesh for Layer 3 Mesh Network</kw>
            <kw>Routing Protocol</kw>
            <kw>Subnet Routing</kw>
            <kw>Distance Vector</kw>
            <kw>Objective Function</kw>
            <kw>DAG for Directed Acyclic Graph</kw>
            <kw>RPL</kw>
        </keywords>
        <abstract><p>The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.</p><p> This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-roll-of0-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC6552</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6553</doc-id>
        <title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams</title>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>LLN</kw>
            <kw>LLNs</kw>
            <kw>Trickle</kw>
        </keywords>
        <abstract><p>The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology.  This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-rpl-option-06</draft>
        <updated-by>
            <doc-id>RFC9008</doc-id>
            <doc-id>RFC9685</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6553</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6554</doc-id>
        <title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>D. Culler</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>LLN</kw>
            <kw>LLNs</kw>
        </keywords>
        <abstract><p>In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes.  In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN.  The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers.  This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-rpl-routing-header-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6555</doc-id>
        <title>Happy Eyeballs: Success with Dual-Stack Hosts</title>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client.  This is undesirable because it causes the dual- stack client to have a worse user experience.  This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-v6ops-happy-eyeballs-07</draft>
        <obsoleted-by>
            <doc-id>RFC8305</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6555</errata-url>
        <doi>10.17487/RFC6555</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6556</doc-id>
        <title>Testing Eyeball Happiness</title>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>test methodology</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>session startup</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract><p>The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment.  This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering.  This test is not a test of a specific algorithm, but of the external behavior of the system as a black box.  Any algorithm that has the intended external behavior will be accepted by it.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-baker-bmwg-testing-eyeball-happiness-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6556</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6557</doc-id>
        <title>Procedures for Maintaining the Time Zone Database</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>P. Eggert</name>
        </author>
        <date>
            <month>February</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
        </keywords>
        <abstract><p>Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP.  The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world.  This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire.  This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community.  The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-lear-iana-timezone-database-05</draft>
        <is-also>
            <doc-id>BCP0175</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6557</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6558</doc-id>
        <title>Sieve Extension for Converting Messages before Delivery</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>K. Li</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Sieve</kw>
            <kw>CONVERT</kw>
        </keywords>
        <abstract><p>This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-convert-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6558</errata-url>
        <doi>10.17487/RFC6558</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6559</doc-id>
        <title>A Reliable Transport Mechanism for PIM</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>M. Napierala</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages.  This eliminates the need for periodic Join/Prune message transmission and processing.  The reliable transport mechanism can use either TCP or SCTP as the transport protocol.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pim-port-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6559</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6560</doc-id>
        <title>One-Time Password (OTP) Pre-Authentication</title>
        <author>
            <name>G. Richards</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data.  This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-otp-preauth-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6560</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6561</doc-id>
        <title>Recommendations for the Remediation of Bots in ISP Networks</title>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>N. Mody</name>
        </author>
        <author>
            <name>M. O'Reirdan</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>Bot</kw>
            <kw>Botnet</kw>
            <kw>Remediation</kw>
            <kw>malware</kw>
            <kw>notification</kw>
        </keywords>
        <abstract><p>This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers.  Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud.  Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack.  Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-oreirdan-mody-bot-remediation-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6561</errata-url>
        <doi>10.17487/RFC6561</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6562</doc-id>
        <title>Guidelines for the Use of Variable Bit Rate Audio with Secure RTP</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>JM. Valin</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>vbr</kw>
        </keywords>
        <abstract><p>This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile.  Guidelines to mitigate these issues are suggested. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtcore-srtp-vbr-audio-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6562</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6563</doc-id>
        <title>Moving A6 to Historic Status</title>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>D. Conrad</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-jiang-a6-to-historic-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6563</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6564</doc-id>
        <title>A Uniform Format for IPv6 Extension Headers</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>J. Woodyatt</name>
        </author>
        <author>
            <name>E. Kline</name>
        </author>
        <author>
            <name>J. Hoagland</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header.  There are a small number of such extension headers currently defined.  This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6.  It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-exthdr-06</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6564</errata-url>
        <doi>10.17487/RFC6564</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6565</doc-id>
        <title>OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol</title>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <author>
            <name>P. Moyer</name>
        </author>
        <author>
            <name>J. Doyle</name>
        </author>
        <author>
            <name>E. Ertekin</name>
        </author>
        <author>
            <name>M. Lundberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>L3VPN</kw>
            <kw>BGP/MPLS</kw>
            <kw>VPN</kw>
        </keywords>
        <abstract><p>Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers.  The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone.  Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified.  This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol.  The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-ospfv3-pece-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC6565</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6566</doc-id>
        <title>A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>G. Martinelli</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.</p><p> This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation. This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ccamp-wson-impairments-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6566</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6567</doc-id>
        <title>Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>L. Liess</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism.  Some SIP sessions are established by or related to a non-SIP application.  This application may have information that needs to be transported between the SIP User Agents during session establishment.  In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-cuss-sip-uui-reqs-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>cuss</wg_acronym>
        <doi>10.17487/RFC6567</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6568</doc-id>
        <title>Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
        <author>
            <name>E. Kim</name>
        </author>
        <author>
            <name>D. Kaspar</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs).  This document provides dimensions of design space for LoWPAN applications.  A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension.  A complete list of practical use cases is not the goal of this document.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-6lowpan-usecases-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lowpan</wg_acronym>
        <doi>10.17487/RFC6568</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6569</doc-id>
        <title>Guidelines for Development of an Audio Codec within the IETF</title>
        <author>
            <name>JM. Valin</name>
        </author>
        <author>
            <name>S. Borilin</name>
        </author>
        <author>
            <name>K. Vos</name>
        </author>
        <author>
            <name>C. Montgomery</name>
        </author>
        <author>
            <name>R. Chen</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>audio codec</kw>
            <kw>speech codec</kw>
        </keywords>
        <abstract><p>This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF.  These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-codec-guidelines-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>codec</wg_acronym>
        <doi>10.17487/RFC6569</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6570</doc-id>
        <title>URI Template</title>
        <author>
            <name>J. Gregorio</name>
        </author>
        <author>
            <name>R. Fielding</name>
        </author>
        <author>
            <name>M. Hadley</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>D. Orchard</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>template</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>URI</kw>
            <kw>URI Template</kw>
            <kw>Internationalized Resource Identifier</kw>
            <kw>IRI</kw>
            <kw>IRI Template</kw>
        </keywords>
        <abstract><p>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion.  This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gregorio-uritemplate-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6570</errata-url>
        <doi>10.17487/RFC6570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6571</doc-id>
        <title>Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Francois</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>M. Horneffer</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>IP Fast Reroute</kw>
            <kw>Routing Convergence</kw>
            <kw>Network Topology</kw>
            <kw>IS-IS</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks.  We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-rtgwg-lfa-applicability-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6571</errata-url>
        <doi>10.17487/RFC6571</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6572</doc-id>
        <title>RADIUS Support for Proxy Mobile IPv6</title>
        <author>
            <name>F. Xia</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>D. Damic</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure.  The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions.  The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain.  Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session.  In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netext-radius-pmip6-08</draft>
        <updated-by>
            <doc-id>RFC8044</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6572</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6573</doc-id>
        <title>The Item and Collection Link Relations</title>
        <author>
            <name>M. Amundsen</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>RFC 5988 standardized a means of indicating the relationships between resources on the Web.  This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-amundsen-item-and-collection-link-relations-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6573</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6574</doc-id>
        <title>Report from the Smart Object Workshop</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>Smart Objects</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-smart-object-workshop-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6574</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6575</doc-id>
        <title>Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs</title>
        <author>
            <name>H. Shah</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Heron</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Kompella</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices.  It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs).  In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology.  However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies.  This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation".  ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit.  The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l2vpn-arp-mediation-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC6575</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6576</doc-id>
        <title>IP Performance Metrics (IPPM) Standard Advancement Testing</title>
        <author>
            <name>R. Geib</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>R. Fardid</name>
        </author>
        <author>
            <name>A. Steinmitz</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>inter-operability</kw>
            <kw>equivalence</kw>
            <kw>measurement</kw>
            <kw>compliance</kw>
            <kw>metric</kw>
        </keywords>
        <abstract><p>This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way.  This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track.  Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods.  The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track.  This document is an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-ippm-metrictest-05</draft>
        <is-also>
            <doc-id>BCP0176</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6576</errata-url>
        <doi>10.17487/RFC6576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6577</doc-id>
        <title>Authentication-Results Registration Update for Sender Policy Framework (SPF) Results</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>SPF</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract><p>This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the Sender Policy Framework (SPF) specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kucherawy-authres-spf-erratum-02</draft>
        <obsoleted-by>
            <doc-id>RFC7001</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5451</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6578</doc-id>
        <title>Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>A. Quillaud</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>sync-collection</kw>
            <kw>sync-token</kw>
        </keywords>
        <abstract><p>This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-daboo-webdav-sync-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6579</doc-id>
        <title>The 'disclosure' Link Relation Type</title>
        <author>
            <name>M. Yevstifeyev</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document specifies the 'disclosure' link relation type.  It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-yevstifeyev-disclosure-relation-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6580</doc-id>
        <title>IANA Registries for the Remote Direct Data Placement (RDDP) Protocols</title>
        <author>
            <name>M. Ko</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
        </keywords>
        <abstract><p>The original RFCs that specified the Remote Direct Data Placement (RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes.  Extensions to the RDDP protocols now require these registries to be created.  This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-storm-rddp-registries-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6580</errata-url>
        <doi>10.17487/RFC6580</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6581</doc-id>
        <title>Enhanced Remote Direct Memory Access (RDMA) Connection Establishment</title>
        <author>
            <name>A. Kanevsky</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bestler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Sharp</name>
        </author>
        <author>
            <name>S. Wise</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment.  The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP).  The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-storm-mpa-peer-connect-09</draft>
        <updates>
            <doc-id>RFC5043</doc-id>
            <doc-id>RFC5044</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC6581</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6582</doc-id>
        <title>The NewReno Modification to TCP's Fast Recovery Algorithm</title>
        <author>
            <name>T. Henderson</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <author>
            <name>Y. Nishida</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>congestion avoidance</kw>
            <kw>congestion control</kw>
            <kw>fast retransmit</kw>
        </keywords>
        <abstract><p>RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK.  This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno".  This response to partial acknowledgments was first proposed by Janey Hoe.  This document obsoletes RFC 3782. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-rfc3782-bis-05</draft>
        <obsoletes>
            <doc-id>RFC3782</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6582</errata-url>
        <doi>10.17487/RFC6582</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6583</doc-id>
        <title>Operational Neighbor Discovery Problems</title>
        <author>
            <name>I. Gashinsky</name>
        </author>
        <author>
            <name>J. Jaeggli</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>March</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.</p><p> This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-v6ops-v6nd-problems-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6583</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6584</doc-id>
        <title>Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols</title>
        <author>
            <name>V. Roca</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>TESLA</kw>
            <kw>FLUTE</kw>
        </keywords>
        <abstract><p>This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols.  The first scheme is based on RSA Digital Signatures.  The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA).  The third scheme relies on a Group- keyed Message Authentication Code (MAC).  Finally, the fourth scheme merges the Digital Signature and group schemes.  These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-simple-auth-for-alc-norm-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC6584</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6585</doc-id>
        <title>Additional HTTP Status Codes</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>R. Fielding</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
        </keywords>
        <abstract><p>This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-nottingham-http-new-status-04</draft>
        <updates>
            <doc-id>RFC2616</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6585</errata-url>
        <doi>10.17487/RFC6585</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6586</doc-id>
        <title>Experiences from an IPv6-Only Network</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>NAT64</kw>
        </keywords>
        <abstract><p>This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device.  The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup.  The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design.  The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-arkko-ipv6-only-experience-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6586</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6587</doc-id>
        <title>Transmission of Syslog Messages over TCP</title>
        <author>
            <name>R. Gerhards</name>
        </author>
        <author>
            <name>C. Lonvick</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SYSLOG</kw>
            <kw>SYSLOG transport TCP</kw>
        </keywords>
        <abstract><p>There have been many implementations and deployments of legacy syslog over TCP for many years.  That protocol has evolved without being standardized and has proven to be quite interoperable in practice.  This memo describes how TCP has been used as a transport for syslog messages.  This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-gerhards-syslog-plain-tcp-14</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6588</doc-id>
        <title>A URN Namespace for ucode</title>
        <author>
            <name>C. Ishikawa</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places.  ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ishikawa-yrpunl-ucode-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6588</errata-url>
        <doi>10.17487/RFC6588</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6589</doc-id>
        <title>Considerations for Transitioning Content to IPv6</title>
        <author>
            <name>J. Livingood</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This document describes considerations for the transition of end-user content on the Internet to IPv6.  While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services.  This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations.  The audience for this document is the Internet community generally, particularly IPv6 implementers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6589</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6590</doc-id>
        <title>Redaction of Potentially Sensitive Data from Mail Abuse Reports</title>
        <author>
            <name>J. Falk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>ARF</kw>
            <kw>MARF</kw>
            <kw>feedback loop</kw>
            <kw>spam reporting</kw>
        </keywords>
        <abstract><p>Email messages often contain information that might be considered private or sensitive, per either regulation or social norms.  When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message.  This memo suggests one method for doing so effectively. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-redaction-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <doi>10.17487/RFC6590</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6591</doc-id>
        <title>Authentication Failure Reporting Using the Abuse Reporting Format</title>
        <author>
            <name>H. Fontana</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>auth</kw>
            <kw>auth failure</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>AFRF</kw>
            <kw>ARF</kw>
        </keywords>
        <abstract><p>This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-authfailure-report-10</draft>
        <updated-by>
            <doc-id>RFC6692</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <doi>10.17487/RFC6591</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6592</doc-id>
        <title>The Null Packet</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined.  This memo corrects that omission.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-pignataro-the-null-packet-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6592</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6593</doc-id>
        <title>Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>J. Clarke</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.</p><p> This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-joegonzalocarlos-service-hide-n-seek-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6593</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6594</doc-id>
        <title>Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records</title>
        <author>
            <name>O. Sury</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
            <kw>SSHFP</kw>
            <kw>SHA-256</kw>
            <kw>Secure Shell</kw>
            <kw>ECDSA</kw>
        </keywords>
        <abstract><p>This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC).  This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-os-ietf-sshfp-ecdsa-sha2-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6594</errata-url>
        <doi>10.17487/RFC6594</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6595</doc-id>
        <title>A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)</title>
        <author>
            <name>K. Wierenga</name>
        </author>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Generic Security Service Application Program Interface</kw>
            <kw>SAML 2.0</kw>
        </keywords>
        <abstract><p>The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On.  The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication.  This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-sasl-saml-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC6595</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6596</doc-id>
        <title>The Canonical Link Relation</title>
        <author>
            <name>M. Ohye</name>
        </author>
        <author>
            <name>J. Kupke</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>RFC 5988 specifies a way to define relationships between links on the web.  This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ohye-canonical-link-relation-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6596</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6597</doc-id>
        <title>RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data</title>
        <author>
            <name>J. Downs</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Arbeiter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>KLV</kw>
        </keywords>
        <abstract><p>This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-payload-rtp-klv-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC6597</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6598</doc-id>
        <title>IANA-Reserved IPv4 Prefix for Shared Address Space</title>
        <author>
            <name>J. Weil</name>
        </author>
        <author>
            <name>V. Kuarsingh</name>
        </author>
        <author>
            <name>C. Donley</name>
        </author>
        <author>
            <name>C. Liljenstolpe</name>
        </author>
        <author>
            <name>M. Azinger</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>shared block</kw>
            <kw>CGN</kw>
            <kw>NAT</kw>
            <kw>Carrier Grade NAT</kw>
            <kw>private address space</kw>
            <kw>service provider</kw>
            <kw>address translation</kw>
            <kw>non-globally routable</kw>
            <kw>non-overlapping address space</kw>
        </keywords>
        <abstract><p>This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).</p><p> Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.</p><p> This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-weil-shared-transition-space-request-15</draft>
        <updates>
            <doc-id>RFC5735</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0153</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6598</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6599</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6600</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6601</doc-id>
        <title>Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks</title>
        <author>
            <name>G. Ash</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. McDysan</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks.  Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress.  Without MPLS GCAC, connections on congested links will suffer degraded quality.  The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers.  MPLS GCAC interoperates between vendor equipment and across multiple service provider domains.  The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF.  The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms.  MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints.  The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request.  In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective.  MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ash-gcac-algorithm-spec-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6601</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6602</doc-id>
        <title>Bulk Binding Update Support for Proxy Mobile IPv6</title>
        <author>
            <name>F. Abinader</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gundavelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>D. Premec</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Proxy Mobile IPv6</kw>
            <kw>PMIPv6</kw>
            <kw>bulk registrations</kw>
            <kw>MN group ID</kw>
        </keywords>
        <abstract><p>For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis.  In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor.  This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netext-bulk-re-registration-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6602</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6603</doc-id>
        <title>Prefix Exclude Option for DHCPv6-based Prefix Delegation</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>OPTION_PD_EXCLUDE</kw>
        </keywords>
        <abstract><p>This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation.  The new mechanism updates RFC 3633. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-pd-exclude-04</draft>
        <updates>
            <doc-id>RFC3633</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6603</errata-url>
        <doi>10.17487/RFC6603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6604</doc-id>
        <title>xNAME RCODE and Status Bits Clarification</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>CNAME</kw>
            <kw>DNAME</kw>
            <kw>Domain Name</kw>
            <kw>response code</kw>
            <kw>canonical name</kw>
        </keywords>
        <abstract><p>The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name.  A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits.  This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-xnamercode-00</draft>
        <updates>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC2672</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6604</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6605</doc-id>
        <title>Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>W.C.A. Wijngaards</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>dnskey algorithm</kw>
            <kw>ds hash algo</kw>
            <kw>crypto</kw>
            <kw>DNS key</kw>
            <kw>DNSKEY algorithm</kw>
            <kw>DS</kw>
            <kw>digest hash cryptography</kw>
            <kw>SHA-384</kw>
            <kw>ECDSAP256SHA256</kw>
            <kw>ECDSAP384SHA384</kw>
        </keywords>
        <abstract><p>This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC).  It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-ecdsa-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6605</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6606</doc-id>
        <title>Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing</title>
        <author>
            <name>E. Kim</name>
        </author>
        <author>
            <name>D. Kaspar</name>
        </author>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>WSN</kw>
            <kw>Sensor Network</kw>
            <kw>Wireless Sensor Network</kw>
            <kw>WSN for Wireless Sensor Network</kw>
            <kw>L3 Mesh for Layer 3 Mesh Network</kw>
            <kw>Routing Protocol</kw>
            <kw>Subnet Routing</kw>
            <kw>ieee 802.15.4</kw>
            <kw>LLN</kw>
            <kw>Low Power</kw>
            <kw>radio 802.15.4</kw>
            <kw>powerline</kw>
            <kw>ISA100.11a</kw>
            <kw>RFC 4944</kw>
        </keywords>
        <abstract><p>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.</p><p> This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-6lowpan-routing-requirements-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lowpan</wg_acronym>
        <doi>10.17487/RFC6606</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6607</doc-id>
        <title>Virtual Subnet Selection Options for DHCPv4 and DHCPv6</title>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>R. Johnson</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>April</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a DHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place.</p><p> For the DHCPv4 option and Relay Agent Information sub-options, this memo documents and extends existing usage as per RFC 3942. This memo updates RFC 3046 regarding details relating to the copying of sub- options (see Section 8).</p></abstract>
        <draft>draft-ietf-dhc-vpn-option-15</draft>
        <updates>
            <doc-id>RFC3046</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6607</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6608</doc-id>
        <title>Subcodes for BGP Finite State Machine Error</title>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>A. Suryanarayana</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines several subcodes for the BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events.  This document updates RFC 4271. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-fsm-subcode-03</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC6608</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6609</doc-id>
        <title>Sieve Email Filtering: Include Extension</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>A. Stone</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another.  This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts.  Users are able to include their own personal scripts or site-wide scripts. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-include-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6609</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6610</doc-id>
        <title>DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)</title>
        <author>
            <name>H. Jang</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <author>
            <name>K. Chowdhury</name>
        </author>
        <author>
            <name>J. Choi</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information.  New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-hiopt-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC6610</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6611</doc-id>
        <title>Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario</title>
        <author>
            <name>K. Chowdhury</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario.  In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer.  In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer.  This document defines a method for home agent information discovery for the integrated scenario. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip6-bootstrapping-integrated-dhc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip6</wg_acronym>
        <doi>10.17487/RFC6611</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6612</doc-id>
        <title>Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues</title>
        <author>
            <name>G. Giaretta</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care.  This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms.  Solutions and recommendations to enable these scenarios are also described.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-netlmm-mip-interactions-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6612</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6613</doc-id>
        <title>RADIUS over TCP</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Remote Authentication Dial-In User Server</kw>
            <kw>Transmission Control Protocol</kw>
            <kw>RADIUS/TCP</kw>
        </keywords>
        <abstract><p>The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer.  This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS).  It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-radext-tcp-transport-09</draft>
        <updated-by>
            <doc-id>RFC7930</doc-id>
            <doc-id>RFC9765</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC6613</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6614</doc-id>
        <title>Transport Layer Security (TLS) Encryption for RADIUS</title>
        <author>
            <name>S. Winter</name>
        </author>
        <author>
            <name>M. McCauley</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>K. Wierenga</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>AAA</kw>
            <kw>Security</kw>
            <kw>Reliability</kw>
            <kw>Remote Authentication Dial-In User Server</kw>
        </keywords>
        <abstract><p>This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol.  This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-radext-radsec-12</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9765</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC6614</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6615</doc-id>
        <title>Definitions of Managed Objects for IP Flow Information Export</title>
        <author>
            <name>T. Dietz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Kobayashi</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>G. Muenz</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>MIB</kw>
            <kw>Filtering</kw>
            <kw>Sampling</kw>
            <kw>Selection</kw>
        </keywords>
        <abstract><p>This document defines managed objects for IP Flow Information eXport (IPFIX).  These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-rfc5815bis-03</draft>
        <obsoletes>
            <doc-id>RFC5815</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC6615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6616</doc-id>
        <title>A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Mauldin</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>web single sign-on</kw>
        </keywords>
        <abstract><p>OpenID has found its usage on the Internet for Web Single Sign-On.  Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication.  This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-kitten-sasl-openid-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6616</errata-url>
        <doi>10.17487/RFC6616</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6617</doc-id>
        <title>Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)</title>
        <author>
            <name>D. Harkins</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Authenticated Key Exchange</kw>
            <kw>Dictionary Attack</kw>
        </keywords>
        <abstract><p>This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE).  It is resistant to dictionary attack and retains security even when used with weak pre-shared keys.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-harkins-ipsecme-spsk-auth-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6617</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6618</doc-id>
        <title>Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Kroeselberg</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>Mobile IPv6</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec.  The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2.  The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack.  This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mext-mip6-tls-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mext</wg_acronym>
        <doi>10.17487/RFC6618</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6619</doc-id>
        <title>Scalable Operation of Address Translators with Per-Interface Bindings</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-arkko-dual-stack-extra-lite-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6619</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6620</doc-id>
        <title>FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>E. Levy-Abegnoli</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>ingress filtering</kw>
            <kw>BCP38</kw>
        </keywords>
        <abstract><p>This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle.  The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-savi-fcfs-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>savi</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6620</errata-url>
        <doi>10.17487/RFC6620</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6621</doc-id>
        <title>Simplified Multicast Forwarding</title>
        <author>
            <name>J. Macker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>flooding</kw>
            <kw>optimized flooding</kw>
            <kw>CDS</kw>
            <kw>connected dominating set</kw>
            <kw>duplicate packet detection</kw>
            <kw>hash-based packet detection</kw>
            <kw>MPR</kw>
            <kw>MPR-CDS</kw>
            <kw>E-CDS</kw>
            <kw>edge mobility</kw>
            <kw>mobile ad hoc</kw>
            <kw>mesh network</kw>
        </keywords>
        <abstract><p>This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use.  It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off.  It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use.  This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.  Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described.  Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices.  Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-manet-smf-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6621</errata-url>
        <doi>10.17487/RFC6621</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6622</doc-id>
        <title>Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)</title>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>packetbb</kw>
            <kw>NHDP</kw>
            <kw>OLSRv2</kw>
            <kw>security</kw>
            <kw>integrity</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444.  It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-manet-packetbb-sec-09</draft>
        <obsoleted-by>
            <doc-id>RFC7182</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC6622</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6623</doc-id>
        <title>IANA Registry for MEDIACTRL Interactive Voice Response Control Package</title>
        <author>
            <name>E. Burger</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, as described in RFC 6231. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mediactrl-6231-iana-00</draft>
        <updates>
            <doc-id>RFC6231</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <doi>10.17487/RFC6623</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6624</doc-id>
        <title>Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>B. Kothari</name>
        </author>
        <author>
            <name>R. Cherukuri</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>L2VPN</kw>
            <kw>discovery</kw>
            <kw>signaling</kw>
            <kw>pseudowire</kw>
        </keywords>
        <abstract><p>Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular.  Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs.  In addition, L2VPN provisioning was cumbersome.  This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-kompella-l2vpn-l2vpn-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6624</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6625</doc-id>
        <title>Wildcards in Multicast VPN Auto-Discovery Routes</title>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Hendrickx</name>
        </author>
        <author>
            <name>R. Qiu</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>mvpn</kw>
        </keywords>
        <abstract><p>In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network.  The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel.  However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel.  Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN.  This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers.  With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-l3vpn-mvpn-wildcards-02</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7582</doc-id>
            <doc-id>RFC7900</doc-id>
            <doc-id>RFC8534</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6625</errata-url>
        <doi>10.17487/RFC6625</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6626</doc-id>
        <title>Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4)</title>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>V. Park</name>
        </author>
        <author>
            <name>V. Narayanan</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>mobile router</kw>
        </keywords>
        <abstract><p>The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks.  This specification defines a dynamic prefix allocation mechanism for NEMOv4. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mip4-nemov4-dynamic-06</draft>
        <updates>
            <doc-id>RFC5177</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC6626</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6627</doc-id>
        <title>Overview of Pre-Congestion Notification Encoding</title>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>T. Moncaster</name>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious \%pre-congestion.</p><p> The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pcn-encoding-comparison-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <doi>10.17487/RFC6627</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6628</doc-id>
        <title>Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2</title>
        <author>
            <name>S. Shin</name>
        </author>
        <author>
            <name>K. Kobara</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>PAKE</kw>
            <kw>augmented PAKE</kw>
            <kw>off-line dictionary attacks</kw>
            <kw>resistance to server compromise</kw>
        </keywords>
        <abstract><p>This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server.  In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks).  The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security).  In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2).  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-shin-augmented-pake-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6628</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6629</doc-id>
        <title>Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>A. Garcia-Martinez</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Cryptographically Generated Address</kw>
            <kw>CGA</kw>
            <kw>Hash-Based Address</kw>
            <kw>HBA</kw>
            <kw>Fault tolerance</kw>
        </keywords>
        <abstract><p>This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-garcia-shim6-applicability-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6629</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6630</doc-id>
        <title>EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)</title>
        <author>
            <name>Z. Cao</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ERP</kw>
            <kw>AAK</kw>
            <kw>EAP</kw>
            <kw>Early-authentication</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.</p><p> The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.</p><p> Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport.</p><p> This document specifies the extensions necessary to enable AAK support in ERP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hokey-erp-aak-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <doi>10.17487/RFC6630</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6631</doc-id>
        <title>Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)</title>
        <author>
            <name>D. Kuegler</name>
        </author>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>pace</kw>
            <kw>password authenticated connection establishment</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords.  Several proposals have been made to integrate password-authentication protocols into IKE.  This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-kuegler-ipsecme-pace-ikev2-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6632</doc-id>
        <title>An Overview of the IETF Network Management Standards</title>
        <author>
            <name>M. Ersue</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>network management</kw>
            <kw>data model</kw>
            <kw>monitoring</kw>
            <kw>configuration</kw>
            <kw>alarm</kw>
            <kw>notification</kw>
        </keywords>
        <abstract><p>This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models.  The document refers to other overview documents, where they exist and classifies the standards for easy orientation.  The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs.  On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models.  This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-opsawg-management-stds-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC6632</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6633</doc-id>
        <title>Deprecation of ICMP Source Quench Messages</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>congestion control</kw>
            <kw>icmp attacks</kw>
            <kw>tcp</kw>
            <kw>tcp security</kw>
            <kw>udp</kw>
            <kw>dccp</kw>
            <kw>sctp</kw>
        </keywords>
        <abstract><p>This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tsvwg-source-quench-06</draft>
        <updates>
            <doc-id>RFC0792</doc-id>
            <doc-id>RFC1122</doc-id>
            <doc-id>RFC1812</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6633</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6634</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6635</doc-id>
        <title>RFC Editor Model (Version 2)</title>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RFC Series Editor</kw>
            <kw>Independenet Series Editor</kw>
            <kw>RSE</kw>
            <kw>ISE</kw>
            <kw>RSOC</kw>
            <kw>RFC Series Oversight Committee</kw>
        </keywords>
        <abstract><p>The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher.  Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC.  This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620, and obsoletes that document.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-rfc-editor-model-v2-05</draft>
        <obsoletes>
            <doc-id>RFC5620</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8728</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6635</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6636</doc-id>
        <title>Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks</title>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>H. Liu</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>May</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Mobility</kw>
            <kw>PMIPv6</kw>
        </keywords>
        <abstract><p>The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other.  This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-multimob-igmp-mld-tuning-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>multimob</wg_acronym>
        <doi>10.17487/RFC6636</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6637</doc-id>
        <title>Elliptic Curve Cryptography (ECC) in OpenPGP</title>
        <author>
            <name>A. Jivsov</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology.  The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-jivsov-openpgp-ecc-14</draft>
        <obsoleted-by>
            <doc-id>RFC9580</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6637</errata-url>
        <doi>10.17487/RFC6637</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6638</doc-id>
        <title>Scheduling Extensions to CalDAV</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>B. Desruisseaux</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>78</page-count>
        <keywords>
            <kw>calsify</kw>
            <kw>calsched</kw>
            <kw>calsch</kw>
            <kw>calendar</kw>
            <kw>calendaring</kw>
            <kw>webcal</kw>
            <kw>ical</kw>
            <kw>icalendar</kw>
            <kw>ischedule</kw>
            <kw>itip</kw>
            <kw>imip</kw>
            <kw>text/calendar</kw>
            <kw>http</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components.  This document defines the "calendar-auto-schedule" feature of CalDAV. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-desruisseaux-caldav-sched-12</draft>
        <updates>
            <doc-id>RFC4791</doc-id>
            <doc-id>RFC5546</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7953</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6638</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6639</doc-id>
        <title>Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview</title>
        <author>
            <name>D. King</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Venkatesan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.</p><p> The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.</p><p> This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-mib-management-overview-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6639</errata-url>
        <doi>10.17487/RFC6639</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6640</doc-id>
        <title>IETF Meeting Attendees' Frequently Asked (Travel) Questions</title>
        <author>
            <name>W. George</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Meetings</kw>
        </keywords>
        <abstract><p>This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information.  It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from.  It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-george-travel-faq-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6640</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6641</doc-id>
        <title>Using DNS SRV to Specify a Global File Namespace with NFS Version 4</title>
        <author>
            <name>C. Everhart</name>
        </author>
        <author>
            <name>W. Adamson</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>domainroot</kw>
            <kw>domain root file system</kw>
        </keywords>
        <abstract><p>The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace.  The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization.  The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC6641</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6642</doc-id>
        <title>RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report</title>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Xia</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Feedback Suppression</kw>
            <kw>NACK</kw>
            <kw>Retransmission</kw>
        </keywords>
        <abstract><p>In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once.  This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports.  However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion.  This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback.  Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtcore-feedback-supression-rtp-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6643</doc-id>
        <title>Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>SMIv2</kw>
            <kw>YANG</kw>
            <kw>data modeling</kw>
        </keywords>
        <abstract><p>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.  The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP).  This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netmod-smi-yang-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6643</errata-url>
        <doi>10.17487/RFC6643</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6644</doc-id>
        <title>Rebind Capability in DHCPv6 Reconfigure Messages</title>
        <author>
            <name>D. Evans</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>internet protocol</kw>
            <kw>parameters</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message.  It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message.  The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-reconfigure-rebind-10</draft>
        <updates>
            <doc-id>RFC3315</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6644</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6645</doc-id>
        <title>IP Flow Information Accounting and Export Benchmarking Methodology</title>
        <author>
            <name>J. Novak</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Flow monitoring</kw>
            <kw>IPFIX</kw>
            <kw>Netflow</kw>
        </keywords>
        <abstract><p>This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector.  It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput.  The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow Information Export".  The methodology quantifies the impact of the IP flow monitoring process on the network equipment.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-bmwg-ipflow-meth-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6645</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6646</doc-id>
        <title>DECoupled Application Data Enroute (DECADE) Problem Statement</title>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>N. Zong</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>R. Alimi</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>In-network storage</kw>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks.  In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network.  Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache.  This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-decade-problem-statement-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>decade</wg_acronym>
        <doi>10.17487/RFC6646</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6647</doc-id>
        <title>Email Greylisting: An Applicability Statement for SMTP</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Email</kw>
            <kw>Greylisting</kw>
            <kw>Spam</kw>
        </keywords>
        <abstract><p>This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.</p><p> Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-appsawg-greylisting-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC6647</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6648</doc-id>
        <title>Deprecating the "X-" Prefix and Similar Constructs in Application Protocols</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs.  In practice, that convention causes more problems than it solves.  Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-appsawg-xdash-05</draft>
        <is-also>
            <doc-id>BCP0178</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6648</errata-url>
        <doi>10.17487/RFC6648</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6649</doc-id>
        <title>Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos</title>
        <author>
            <name>L. Hornquist Astrand</name>
        </author>
        <author>
            <name>T. Yu</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption.  Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure.  By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average.  DES is long past its sell-by date.  Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos.  Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-krb-wg-des-die-die-die-04</draft>
        <obsoletes>
            <doc-id>RFC1510</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1964</doc-id>
            <doc-id>RFC4120</doc-id>
            <doc-id>RFC4121</doc-id>
            <doc-id>RFC4757</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0179</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6649</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6650</doc-id>
        <title>Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)</title>
        <author>
            <name>J. Falk</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>marf</kw>
            <kw>spam reporting</kw>
        </keywords>
        <abstract><p>RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties.  This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events.  Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them.  Some related optional mechanisms are also discussed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-as-16</draft>
        <updates>
            <doc-id>RFC5965</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <doi>10.17487/RFC6650</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6651</doc-id>
        <title>Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>fraud</kw>
            <kw>phishing</kw>
            <kw>spoofing</kw>
        </keywords>
        <abstract><p>This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-dkim-reporting-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <doi>10.17487/RFC6651</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6652</doc-id>
        <title>Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format</title>
        <author>
            <name>S. Kitterman</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>fraud</kw>
            <kw>phishing</kw>
            <kw>spoofing</kw>
        </keywords>
        <abstract><p>This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.</p><p> This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-marf-spf-reporting-11</draft>
        <updates>
            <doc-id>RFC4408</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>marf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6652</errata-url>
        <doi>10.17487/RFC6652</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6653</doc-id>
        <title>DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks</title>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>F. Xia</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document.  Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server.  The access router first requests a prefix for an incoming mobile node from the DHCPv6 server.  The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP.  We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-sarikaya-v6ops-prefix-delegation-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6654</doc-id>
        <title>Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)</title>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <author>
            <name>Q. Chen</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IPv6 transition</kw>
        </keywords>
        <abstract><p>This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969.  The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels.  6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address.  The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd).  The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment.  The latter point means less pressure on IPv4 addresses in a high-growth environment.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-tsou-softwire-gwinit-6rd-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6654</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6655</doc-id>
        <title>AES-CCM Cipher Suites for Transport Layer Security (TLS)</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>D. Bailey</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Authentication</kw>
            <kw>Encryption</kw>
            <kw>Advanced Encryption Standard (AES)</kw>
        </keywords>
        <abstract><p>This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication.  The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-mcgrew-tls-aes-ccm-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6655</errata-url>
        <doi>10.17487/RFC6655</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6656</doc-id>
        <title>Description of Cisco Systems' Subnet Allocation Option for DHCPv4</title>
        <author>
            <name>R. Johnson</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4.  The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics.  This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-dhc-subnet-alloc-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6656</errata-url>
        <doi>10.17487/RFC6656</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6657</doc-id>
        <title>Update to MIME regarding "charset" Parameter Handling in Textual Media Types</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MIME</kw>
            <kw>charset</kw>
            <kw>text</kw>
        </keywords>
        <abstract><p>This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-appsawg-mime-default-charset-04</draft>
        <updates>
            <doc-id>RFC2046</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC6657</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6658</doc-id>
        <title>Packet Pseudowire Encapsulation over an MPLS PSN</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment.  This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-packet-pw-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6658</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6659</doc-id>
        <title>Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method</title>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IPTV</kw>
            <kw>FEC</kw>
            <kw>retransmission</kw>
        </keywords>
        <abstract><p>The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data.  Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate.  This often precedes, but may also accompany, the multicast stream itself.  When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner.  However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately.  This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-avtext-rams-scenarios-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC6659</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6660</doc-id>
        <title>Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)</title>
        <author>
            <name>B. Briscoe</name>
        </author>
        <author>
            <name>T. Moncaster</name>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Congestion Control</kw>
            <kw>Congestion Notification</kw>
            <kw>Tunnelling</kw>
            <kw>Encapsulation &amp; Decapsulation</kw>
            <kw>Differentiated Services</kw>
            <kw>Integrated Services</kw>
            <kw>Signalling</kw>
            <kw>Protocol</kw>
            <kw>Flow Admission Control</kw>
            <kw>Flow Termination</kw>
        </keywords>
        <abstract><p>The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.</p><p> This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pcn-3-in-1-encoding-11</draft>
        <obsoletes>
            <doc-id>RFC5696</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <doi>10.17487/RFC6660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6661</doc-id>
        <title>Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation</title>
        <author>
            <name>A. Charny</name>
        </author>
        <author>
            <name>F. Huang</name>
        </author>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>PCN</kw>
            <kw>controlled load</kw>
            <kw>CL</kw>
            <kw>boundary node behavior</kw>
        </keywords>
        <abstract><p>Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain.  The overall PCN architecture is described in RFC 5559.  This memo is one of a series describing possible boundary-node behaviors for a PCN-domain.  The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked.  This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pcn-cl-edge-behaviour-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <doi>10.17487/RFC6661</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6662</doc-id>
        <title>Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation</title>
        <author>
            <name>A. Charny</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>PCN</kw>
            <kw>single marking</kw>
            <kw>SM</kw>
            <kw>edge node behavior</kw>
        </keywords>
        <abstract><p>Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain.  The overall PCN architecture is described in RFC 5559.  This memo is one of a series describing possible boundary-node behaviors for a PCN-domain.  The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked.  This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pcn-sm-edge-behaviour-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <doi>10.17487/RFC6662</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6663</doc-id>
        <title>Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain</title>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain.  The overall PCN architecture is described in RFC 5559.  This memo describes the requirements for the signaling applied within the PCN-domain: (1) PCN-feedback-information is carried from the PCN-egress-node to the Decision Point; (2) the Decision Point may ask the PCN-ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node.  The Decision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required).  The signaling requirements pertain in particular to two edge behaviors, Controlled Load (CL) and Single Marking (SM).  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pcn-signaling-requirements-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>pcn</wg_acronym>
        <doi>10.17487/RFC6663</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6664</doc-id>
        <title>S/MIME Capabilities for Public Key Definitions</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>OCSP</kw>
            <kw>CMS</kw>
        </keywords>
        <abstract><p>This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group.  This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pkix-pubkey-caps-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC6664</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6665</doc-id>
        <title>SIP-Specific Event Notification</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>SUBSCRIBE</kw>
            <kw>NOTIFY</kw>
            <kw>state</kw>
        </keywords>
        <abstract><p>This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. 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.</p><p> Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.</p><p> This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-rfc3265bis-09</draft>
        <obsoletes>
            <doc-id>RFC3265</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC4660</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7621</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC6665</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6666</doc-id>
        <title>A Discard Prefix for IPv6</title>
        <author>
            <name>N. Hilliard</name>
        </author>
        <author>
            <name>D. Freedman</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>RTBH</kw>
            <kw>black hole</kw>
        </keywords>
        <abstract><p>Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address.  Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address.  This document updates the "IPv6 Special Purpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-discard-prefix-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6667</doc-id>
        <title>LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements</title>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired.  However, a Typed Wildcard FEC Element must be individually defined for each FEC Element type.  This specification defines the Typed Wildcard FEC Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-pw-typed-wc-fec-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6667</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6668</doc-id>
        <title>SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol</title>
        <author>
            <name>D. Bider</name>
        </author>
        <author>
            <name>M. Baushke</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol.  It also updates RFC 4253 by specifying a new RECOMMENDED data integrity algorithm. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-dbider-sha2-mac-for-ssh-06</draft>
        <updates>
            <doc-id>RFC4253</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6668</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6669</doc-id>
        <title>An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks</title>
        <author>
            <name>N. Sprecher</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks.  The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels.  This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets.  The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mpls-tp-oam-analysis-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6669</errata-url>
        <doi>10.17487/RFC6669</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6670</doc-id>
        <title>The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)</title>
        <author>
            <name>N. Sprecher</name>
        </author>
        <author>
            <name>KY. Hong</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.</p><p> During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.</p><p> One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-sprecher-mpls-tp-oam-considerations-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6670</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6671</doc-id>
        <title>Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)</title>
        <author>
            <name>M. Betts</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, and Management (MPLS-TP OAM) messages in the MPLS Generic Associated Channel.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-betts-itu-oam-ach-code-point-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6671</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6672</doc-id>
        <title>DNAME Redirection in the DNS</title>
        <author>
            <name>S. Rose</name>
        </author>
        <author>
            <name>W. Wijngaards</name>
        </author>
        <date>
            <month>June</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
        </keywords>
        <abstract><p>The DNAME record provides redirection for a subtree of the domain name tree in the DNS.  That is, all names that end with a particular suffix are redirected to another part of the DNS.  This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-rfc2672bis-dname-26</draft>
        <obsoletes>
            <doc-id>RFC2672</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3363</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6672</errata-url>
        <doi>10.17487/RFC6672</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6673</doc-id>
        <title>Round-Trip Packet Loss Metrics</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IP</kw>
            <kw>IPPM</kw>
        </keywords>
        <abstract><p>Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.</p><p> This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ippm-rt-loss-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6673</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6674</doc-id>
        <title>Gateway-Initiated Dual-Stack Lite Deployment</title>
        <author>
            <name>F. Brockners</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>S. Speicher</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>GI-DS-Lite</kw>
            <kw>Gateway Initiated Dual-Stack Lite</kw>
            <kw>Dual-Stack Lite</kw>
            <kw>IPv6 Transitioning</kw>
            <kw>IPv6 Migration</kw>
        </keywords>
        <abstract><p>Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures.  GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong.  The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-softwire-gateway-init-ds-lite-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC6674</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6675</doc-id>
        <title>A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP</title>
        <author>
            <name>E. Blanton</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>I. Jarvinen</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <author>
            <name>Y. Nishida</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>retransmission</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>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 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.  This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-tcpm-3517bis-02</draft>
        <obsoletes>
            <doc-id>RFC3517</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6675</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6676</doc-id>
        <title>Multicast Addresses for Documentation</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>R. Parekh</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>M. Eubanks</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use.  Some multicast addresses are derived from AS numbers or unicast addresses.  This document also explains how these can be used for documentation purposes.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mboned-mcaddrdoc-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC6676</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6677</doc-id>
        <title>Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods</title>
        <author>
            <name>S. Hartman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Clancy</name>
        </author>
        <author>
            <name>K. Hoeper</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-emu-chbind-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC6677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6678</doc-id>
        <title>Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method</title>
        <author>
            <name>K. Hoeper</name>
        </author>
        <author>
            <name>S. Hanna</name>
        </author>
        <author>
            <name>H. Zhou</name>
        </author>
        <author>
            <name>J. Salowey</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method.  This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel.  The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-emu-eaptunnel-req-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC6678</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6679</doc-id>
        <title>Explicit Congestion Notification (ECN) for RTP over UDP</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>I. Johansson</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>P. O'Hanlon</name>
        </author>
        <author>
            <name>K. Carlberg</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>ECN</kw>
            <kw>RTP</kw>
            <kw>UDP</kw>
            <kw>Congestion Control</kw>
            <kw>VoIP</kw>
            <kw>IPTV</kw>
            <kw>Packet Loss</kw>
        </keywords>
        <abstract><p>This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism.  It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE).  Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-avtcore-ecn-for-rtp-08</draft>
        <updated-by>
            <doc-id>RFC8311</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6679</errata-url>
        <doi>10.17487/RFC6679</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6680</doc-id>
        <title>Generic Security Service Application Programming Interface (GSS-API) Naming Extensions</title>
        <author>
            <name>N. Williams</name>
        </author>
        <author>
            <name>L. Johansson</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization.  This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.</p></abstract>
        <draft>draft-ietf-kitten-gssapi-naming-exts-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6680</errata-url>
        <doi>10.17487/RFC6680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6681</doc-id>
        <title>Raptor Forward Error Correction (FEC) Schemes for FECFRAME</title>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework.  The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow.  The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity.  Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number.  Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fecframe-raptor-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6681</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6682</doc-id>
        <title>RTP Payload Format for Raptor Forward Error Correction (FEC)</title>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes.  Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP.  This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-fecframe-rtp-raptor-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6682</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6683</doc-id>
        <title>Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>DVB</kw>
            <kw>FEC</kw>
            <kw>AL-FEC</kw>
            <kw>IPTV</kw>
            <kw>parity codes</kw>
            <kw>Raptor codes</kw>
        </keywords>
        <abstract><p>Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP.  The DVB-IPTV AL-FEC protocol uses two layers for FEC protection.  The first (base) layer is based on the 1-D interleaved parity code.  The second (enhancement) layer is based on the Raptor code.  By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity.  This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-fecframe-dvb-al-fec-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6683</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6684</doc-id>
        <title>Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>mile</kw>
            <kw>incident handling</kw>
        </keywords>
        <abstract><p>This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-mile-template-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC6684</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6685</doc-id>
        <title>Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>mile</kw>
            <kw>xml schema</kw>
        </keywords>
        <abstract><p>This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mile-iodef-xmlreg-01</draft>
        <obsoleted-by>
            <doc-id>RFC7970</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5070</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC6685</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6686</doc-id>
        <title>Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SPF</kw>
            <kw>Sender ID</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.</p><p> The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.</p><p> After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-spfbis-experiment-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>spfbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6686</errata-url>
        <doi>10.17487/RFC6686</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6687</doc-id>
        <title>Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
        <author>
            <name>J. Tripathi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. de Oliveira</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JP. Vasseur</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>ROLL</kw>
        </keywords>
        <abstract><p>This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network.  Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios.  Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-tripathi-roll-rpl-simulation-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6687</errata-url>
        <doi>10.17487/RFC6687</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6688</doc-id>
        <title>Parallel NFS (pNFS) Block Disk Protection</title>
        <author>
            <name>D. Black</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Glasgow</name>
        </author>
        <author>
            <name>S. Faibish</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>NFS</kw>
            <kw>NFSv4</kw>
            <kw>pNFS</kw>
            <kw>SAN</kw>
            <kw>GPT</kw>
        </keywords>
        <abstract><p>Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server.  This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used.  The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server.  This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server.  This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-nfsv4-pnfs-block-disk-protection-03</draft>
        <updates>
            <doc-id>RFC5663</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC6688</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6689</doc-id>
        <title>Usage of the RSVP ASSOCIATION Object</title>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Resource Reservation Protocol</kw>
        </keywords>
        <abstract><p>The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs).  In this context, the object is used to associate recovery LSPs with the LSP they are protecting.  This document reviews how the association is to be provided in the context of GMPLS recovery.  No new procedures or mechanisms are defined by this document, and it is strictly informative in nature.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ccamp-assoc-info-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6689</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6690</doc-id>
        <title>Constrained RESTful Environments (CoRE) Link Format</title>
        <author>
            <name>Z. Shelby</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>CoRE</kw>
            <kw>Link Format</kw>
            <kw>HTTP Link Header Format</kw>
            <kw>Resource Discovery</kw>
        </keywords>
        <abstract><p>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-core-link-format-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6690</errata-url>
        <doi>10.17487/RFC6690</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6691</doc-id>
        <title>TCP Options and Maximum Segment Size (MSS)</title>
        <author>
            <name>D. Borman</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-tcpm-tcpmss-05</draft>
        <obsoleted-by>
            <doc-id>RFC9293</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0879</doc-id>
            <doc-id>RFC2385</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6691</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6692</doc-id>
        <title>Source Ports in Abuse Reporting Format (ARF) Reports</title>
        <author>
            <name>R. Clayton</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ARF</kw>
            <kw>ports</kw>
            <kw>reporting</kw>
            <kw>feedback</kw>
        </keywords>
        <abstract><p>This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.</p><p> This document updates RFC 6591. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-kucherawy-marf-source-ports-05</draft>
        <updates>
            <doc-id>RFC6591</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6692</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6693</doc-id>
        <title>Probabilistic Routing Protocol for Intermittently Connected Networks</title>
        <author>
            <name>A. Lindgren</name>
        </author>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>S. Grasic</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>113</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>Routing</kw>
            <kw>PRoPHET</kw>
        </keywords>
        <abstract><p>This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.</p><p> This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the \%best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-dtnrg-prophet-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6693</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6694</doc-id>
        <title>The "about" URI Scheme</title>
        <author>
            <name>S. Moonesamy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-appsawg-about-uri-scheme-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC6694</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6695</doc-id>
        <title>Methods to Convey Forward Error Correction (FEC) Framework Configuration Information</title>
        <author>
            <name>R. Asati</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).</p><p> This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-fecframe-config-signaling-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6695</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6696</doc-id>
        <title>EAP Extensions for the EAP Re-authentication Protocol (ERP)</title>
        <author>
            <name>Z. Cao</name>
        </author>
        <author>
            <name>B. He</name>
        </author>
        <author>
            <name>Y. Shi</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>EAP keying</kw>
            <kw>EMSK</kw>
            <kw>inter-authenticator roaming</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.  In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator.  This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator.  The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-hokey-rfc5296bis-07</draft>
        <obsoletes>
            <doc-id>RFC5296</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <doi>10.17487/RFC6696</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6697</doc-id>
        <title>Handover Keying (HOKEY) Architecture Design</title>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>K. Hoeper</name>
        </author>
        <author>
            <name>S. Decugis</name>
        </author>
        <date>
            <month>July</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Handover Keying Architecture</kw>
            <kw>Re-authentication</kw>
            <kw>Early authentication</kw>
        </keywords>
        <abstract><p>The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.</p><p> This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-hokey-arch-design-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>hokey</wg_acronym>
        <doi>10.17487/RFC6697</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6698</doc-id>
        <title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Schlyter</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>certificates</kw>
            <kw>public keys</kw>
            <kw>PKI</kw>
        </keywords>
        <abstract><p>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers.  This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dane-protocol-23</draft>
        <updated-by>
            <doc-id>RFC7218</doc-id>
            <doc-id>RFC7671</doc-id>
            <doc-id>RFC8749</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6698</errata-url>
        <doi>10.17487/RFC6698</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6699</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6700</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6701</doc-id>
        <title>Sanctions Available for Application to Violators of IETF IPR Policy</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>P. Resnick</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.</p><p> The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.</p><p> This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-farrresnickel-ipr-sanctions-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6701</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6702</doc-id>
        <title>Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules</title>
        <author>
            <name>T. Polk</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus.  However, this process is not always followed by IETF participants.  Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications.  This document describes some strategies for promoting compliance with the IPR disclosure rules.  These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-polk-ipr-disclosure-05</draft>
        <updated-by>
            <doc-id>RFC8717</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6702</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6703</doc-id>
        <title>Reporting IP Network Performance Metrics: Different Points of View</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>G. Ramachandran</name>
        </author>
        <author>
            <name>G. Maguluri</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Loss</kw>
            <kw>Delay</kw>
            <kw>Delay Variation</kw>
            <kw>Capacity</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>Consumers of IP network performance metrics have many different uses in mind.  This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences.  It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ippm-reporting-metrics-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6703</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6704</doc-id>
        <title>Forcerenew Nonce Authentication</title>
        <author>
            <name>D. Miles</name>
        </author>
        <author>
            <name>W. Dec</name>
        </author>
        <author>
            <name>J. Bristow</name>
        </author>
        <author>
            <name>R. Maglione</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DHCP</kw>
        </keywords>
        <abstract><p>Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server.  In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message.  This document updates RFC 3203. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-forcerenew-nonce-07</draft>
        <updates>
            <doc-id>RFC3203</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6704</errata-url>
        <doi>10.17487/RFC6704</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6705</doc-id>
        <title>Localized Routing for Proxy Mobile IPv6</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <author>
            <name>P. Loureiro</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>A. Dutta</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>PMIPv6</kw>
        </keywords>
        <abstract><p>Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling.  PMIPv6 requires all communications to go through the local mobility anchor.  As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways.  This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain.  It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netext-pmip-lr-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6705</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6706</doc-id>
        <title>Asymmetric Extended Route Optimization (AERO)</title>
        <author>
            <name>F. Templin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>route</kw>
            <kw>optimize</kw>
            <kw>optimization</kw>
            <kw>redirect</kw>
            <kw>redirection</kw>
            <kw>protocol</kw>
            <kw>routing</kw>
            <kw>link</kw>
            <kw>multi-access</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection.  Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination.  This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress.  However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.  This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-templin-aero-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6706</errata-url>
        <doi>10.17487/RFC6706</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6707</doc-id>
        <title>Content Distribution Network Interconnection (CDNI) Problem Statement</title>
        <author>
            <name>B. Niven-Jenkins</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>Delivery</kw>
            <kw>CDN</kw>
        </keywords>
        <abstract><p>Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.</p><p> The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-cdni-problem-statement-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC6707</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6708</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Requirements</title>
        <author>
            <name>S. Kiesel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>R. Woundy</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.</p><p> This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-alto-reqs-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC6708</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6709</doc-id>
        <title>Design Considerations for Protocol Extensions</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations.  It is intended to assist designers of both base protocols and extensions.  Case studies are included.  A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-extension-recs-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6709</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6710</doc-id>
        <title>Simple Mail Transfer Protocol Extension for Message Transfer Priorities</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>K. Carlberg</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>priority</kw>
            <kw>MMHS</kw>
        </keywords>
        <abstract><p>This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-melnikov-smtp-priority-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6710</errata-url>
        <doi>10.17487/RFC6710</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6711</doc-id>
        <title>An IANA Registry for Level of Assurance (LoA) Profiles</title>
        <author>
            <name>L. Johansson</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Identity</kw>
            <kw>Assurance</kw>
        </keywords>
        <abstract><p>This document establishes an IANA registry for Level of Assurance (LoA) Profiles.  The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-johansson-loa-registry-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6711</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6712</doc-id>
        <title>Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)</title>
        <author>
            <name>T. Kause</name>
        </author>
        <author>
            <name>M. Peylo</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>CMPtrans</kw>
        </keywords>
        <abstract><p>This document describes how to layer the Certificate Management Protocol (CMP) over HTTP.  It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-cmp-transport-protocols-20</draft>
        <obsoleted-by>
            <doc-id>RFC9811</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4210</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9480</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC6712</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6713</doc-id>
        <title>The 'application/zlib' and 'application/gzip' Media Types</title>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>compress</kw>
            <kw>deflate</kw>
            <kw>stream compression</kw>
        </keywords>
        <abstract><p>This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-levine-application-gzip-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6713</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6714</doc-id>
        <title>Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>S. Blau</name>
        </author>
        <author>
            <name>E. Burger</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Middlebox</kw>
            <kw>IBCF</kw>
            <kw>SBC</kw>
        </keywords>
        <abstract><p>This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA).  Support of this extension is OPTIONAL.  The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed.  This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-simple-msrp-cema-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC6714</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6715</doc-id>
        <title>vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group</title>
        <author>
            <name>D. Cauchie</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>K. Li</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>expertise</kw>
            <kw>hobby</kw>
            <kw>interest</kw>
        </keywords>
        <abstract><p>This document defines extensions to the vCard data format for representing and exchanging certain contact information.  The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-vcarddav-oma-cab-extensions-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>vcarddav</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6715</errata-url>
        <doi>10.17487/RFC6715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6716</doc-id>
        <title>Definition of the Opus Audio Codec</title>
        <author>
            <name>JM. Valin</name>
        </author>
        <author>
            <name>K. Vos</name>
        </author>
        <author>
            <name>T. Terriberry</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>326</page-count>
        <keywords>
            <kw>voice</kw>
            <kw>music</kw>
            <kw>lossy compression</kw>
            <kw>VOIP</kw>
        </keywords>
        <abstract><p>This document defines the Opus interactive speech and audio codec.  Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances.  It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s.  Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-codec-opus-16</draft>
        <updated-by>
            <doc-id>RFC8251</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>codec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6716</errata-url>
        <doi>10.17487/RFC6716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6717</doc-id>
        <title>kx509 Kerberized Certificate Issuance Protocol in Use in 2012</title>
        <author>
            <name>H. Hotz</name>
        </author>
        <author>
            <name>R. Allbery</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Kerberos</kw>
            <kw>X.509</kw>
            <kw>kx509</kw>
            <kw>KCA</kw>
            <kw>kca-service</kw>
            <kw>kca_service</kw>
        </keywords>
        <abstract><p>This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.</p><p> While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-hotz-kx509-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6717</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6718</doc-id>
        <title>Pseudowire Redundancy</title>
        <author>
            <name>P. Muley</name>
        </author>
        <author>
            <name>M. Aissaoui</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Active</kw>
            <kw>standby</kw>
            <kw>protection</kw>
            <kw>dual-homing</kw>
            <kw>vpls</kw>
            <kw>vpws</kw>
        </keywords>
        <abstract><p>This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy.  A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications.  In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pwe3-redundancy-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6719</doc-id>
        <title>The Minimum Rank with Hysteresis Objective Function</title>
        <author>
            <name>O. Gnawali</name>
        </author>
        <author>
            <name>P. Levis</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Routing Protocol for Low Power and Lossy Networks</kw>
            <kw>RPL</kw>
            <kw>Low Power and Lossy Networks</kw>
            <kw>LLN</kw>
        </keywords>
        <abstract><p>The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses.  This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes.  MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-roll-minrank-hysteresis-of-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6719</errata-url>
        <doi>10.17487/RFC6719</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6720</doc-id>
        <title>The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>GTSM</kw>
            <kw>LDP</kw>
        </keywords>
        <abstract><p>The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router\'s IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).</p><p> This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ldp-gtsm-09</draft>
        <updates>
            <doc-id>RFC5036</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7552</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6720</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6721</doc-id>
        <title>The Atom "deleted-entry" Element</title>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Atom Feed</kw>
            <kw>Entry Documents</kw>
        </keywords>
        <abstract><p>This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-snell-atompub-tombstones-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6721</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6722</doc-id>
        <title>Publishing the "Tao of the IETF" as a Web Page</title>
        <author>
            <name>P. Hoffman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page.  It also contains the procedure for publishing and editing that web page.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-hoffman-tao-as-web-page-04</draft>
        <obsoletes>
            <doc-id>RFC4677</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9592</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6722</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6723</doc-id>
        <title>Update of the Pseudowire Control-Word Negotiation Mechanism</title>
        <author>
            <name>L. Jin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Key</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Delord</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>control word</kw>
            <kw>control word negotiation</kw>
            <kw>control word renegotiation</kw>
            <kw>control word negotiation mechanism</kw>
            <kw>control word renegotiation mechanism</kw>
        </keywords>
        <abstract><p>The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED.  This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pwe3-cbit-negotiation-05</draft>
        <obsoleted-by>
            <doc-id>RFC8077</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4447</doc-id>
            <doc-id>RFC6073</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC6723</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6724</doc-id>
        <title>Default Address Selection for Internet Protocol Version 6 (IPv6)</title>
        <author>
            <name>D. Thaler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Draves</name>
        </author>
        <author>
            <name>A. Matsumoto</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>source</kw>
            <kw>destination</kw>
            <kw>sort</kw>
            <kw>sorting</kw>
        </keywords>
        <abstract><p>This document describes two algorithms, one for source address selection and one 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.</p><p> Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-rfc3484bis-06</draft>
        <obsoletes>
            <doc-id>RFC3484</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6724</errata-url>
        <doi>10.17487/RFC6724</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6725</doc-id>
        <title>DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates</title>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>August</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data.  The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry.  This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-registry-update-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6725</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6726</doc-id>
        <title>FLUTE - File Delivery over Unidirectional Transport</title>
        <author>
            <name>T. Paila</name>
        </author>
        <author>
            <name>R. Walsh</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>R. Lehtonen</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>This document defines File Delivery over Unidirectional Transport (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 document obsoletes RFC 3926. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-rmt-flute-revised-16</draft>
        <obsoletes>
            <doc-id>RFC3926</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6726</errata-url>
        <doi>10.17487/RFC6726</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6727</doc-id>
        <title>Definitions of Managed Objects for Packet Sampling</title>
        <author>
            <name>T. Dietz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>PSAMP</kw>
            <kw>IPFIX</kw>
            <kw>MIB</kw>
            <kw>Sampling</kw>
            <kw>Filtering</kw>
            <kw>Selection</kw>
        </keywords>
        <abstract><p>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 extensions to the IPFIX-SELECTOR-MIB module.  For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- MIB module containing managed objects for providing information on applied packet selection functions and their parameters. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-psamp-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC6727</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6728</doc-id>
        <title>Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols</title>
        <author>
            <name>G. Muenz</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>129</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>PSAMP</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols.  It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF).  The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG.  The configuration data is encoded in Extensible Markup Language (XML). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ipfix-configuration-model-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6728</errata-url>
        <doi>10.17487/RFC6728</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6729</doc-id>
        <title>Indicating Email Handling States in Trace Fields</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Quarantine</kw>
            <kw>Moderation</kw>
        </keywords>
        <abstract><p>This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions.  This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-appsawg-received-state-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6729</errata-url>
        <doi>10.17487/RFC6729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6730</doc-id>
        <title>Requirements for IETF Nominations Committee Tools</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines the requirements for a set of tools for use by the IETF Nominations Committee.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-krishnan-nomcom-tools-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6730</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6731</doc-id>
        <title>Improved Recursive DNS Server Selection for Multi-Interfaced Nodes</title>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>J. Kato</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>RDNSS</kw>
            <kw>interface</kw>
            <kw>FQDN</kw>
            <kw>selection</kw>
        </keywords>
        <abstract><p>A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces.  A node commonly receives recursive DNS server configuration information from all connected networks.  Some of the recursive DNS servers might have information about namespaces other servers do not have.  When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use.  This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mif-dns-server-selection-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mif</wg_acronym>
        <doi>10.17487/RFC6731</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6732</doc-id>
        <title>6to4 Provider Managed Tunnels</title>
        <author>
            <name>V. Kuarsingh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>O. Vautrin</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>6to4-PMT</kw>
        </keywords>
        <abstract><p>6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration.  The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation.  6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation.  This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation.  6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07</draft>
        <obsoleted-by>
            <doc-id>RFC7526</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6732</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6733</doc-id>
        <title>Diameter Base Protocol</title>
        <author>
            <name>V. Fajardo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>152</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>AAA</kw>
        </keywords>
        <abstract><p>The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations.  This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications.  The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-rfc3588bis-33</draft>
        <obsoletes>
            <doc-id>RFC3588</doc-id>
            <doc-id>RFC5719</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7075</doc-id>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6733</errata-url>
        <doi>10.17487/RFC6733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6734</doc-id>
        <title>Diameter Attribute-Value Pairs for Cryptographic Key Transport</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>V. Cakulev</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>AAA,ERP,MSK</kw>
        </keywords>
        <abstract><p>Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material.  This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-local-keytran-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC6734</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6735</doc-id>
        <title>Diameter Priority Attribute-Value Pairs</title>
        <author>
            <name>K. Carlberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>AVP</kw>
        </keywords>
        <abstract><p>This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework.  The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-priority-avps-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6735</errata-url>
        <doi>10.17487/RFC6735</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6736</doc-id>
        <title>Diameter Network Address and Port Translation Control Application</title>
        <author>
            <name>F. Brockners</name>
        </author>
        <author>
            <name>S. Bhandari</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>V. Fajardo</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>NAT control</kw>
            <kw>NAT44</kw>
            <kw>NAT66</kw>
            <kw>CGN</kw>
            <kw>BNG</kw>
        </keywords>
        <abstract><p>This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application.  This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion.  This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component.  These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers.  This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device.  This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint.  In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-nat-control-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC6736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6737</doc-id>
        <title>The Diameter Capabilities Update Application</title>
        <author>
            <name>K. Jiao</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document defines a new Diameter application and associated Command Codes.  The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-capablities-update-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC6737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6738</doc-id>
        <title>Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers</title>
        <author>
            <name>V. Cakulev</name>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <author>
            <name>S. Mizikovsky</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Internet Key Exchange Protocol version 2</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).</p><p> Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dime-ikev2-psk-diameter-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC6738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6739</doc-id>
        <title>Synchronizing Service Boundaries and &lt;mapping&gt; Elements Based on the Location-to-Service Translation (LoST) Protocol</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Location</kw>
        </keywords>
        <abstract><p>The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.</p><p> The &lt;mapping&gt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.</p><p> This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative &lt;mapping&gt; elements between two entities. Exchanging cached &lt;mapping&gt; elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the &lt;mapping&gt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ecrit-lost-sync-18</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6739</errata-url>
        <doi>10.17487/RFC6739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6740</doc-id>
        <title>Identifier-Locator Network Protocol (ILNP) Architectural Description</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-arch-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6740</errata-url>
        <doi>10.17487/RFC6740</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6741</doc-id>
        <title>Identifier-Locator Network Protocol (ILNP) Engineering Considerations</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-eng-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6742</doc-id>
        <title>DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This note describes additional optional resource records for use with the Domain Name System (DNS).  These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP).  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-dns-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6742</errata-url>
        <doi>10.17487/RFC6742</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6743</doc-id>
        <title>ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP).  The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP.  This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-icmpv6-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6743</errata-url>
        <doi>10.17487/RFC6743</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6744</doc-id>
        <title>IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP.  ILNP has multiple instantiations.  This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6).  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-noncev6-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6745</doc-id>
        <title>ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP).  ILNP is an experimental, evolutionary enhancement to IP.  The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-icmpv4-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6746</doc-id>
        <title>IPv4 Options for the Identifier-Locator Network Protocol (ILNP)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4).  ILNP is an experimental, evolutionary enhancement to IP.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-v4opts-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6746</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6747</doc-id>
        <title>Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).  ILNP is an experimental, evolutionary enhancement to IP.  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-arp-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6747</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6748</doc-id>
        <title>Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)</title>
        <author>
            <name>RJ Atkinson</name>
        </author>
        <author>
            <name>SN Bhatti</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP.  None of the functions described here is required for the use or deployment of ILNP.  Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-irtf-rrg-ilnp-adv-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6748</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6749</doc-id>
        <title>The OAuth 2.0 Authorization Framework</title>
        <author>
            <name>D. Hardt</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>Client</kw>
            <kw>Resource Owner</kw>
            <kw>Authorization Server</kw>
            <kw>Resource Server</kw>
            <kw>Token Endpoint</kw>
            <kw>Authorization Endpoint</kw>
            <kw>Authorization Request</kw>
            <kw>Authorization Grant</kw>
            <kw>Protected Resource</kw>
            <kw>Access Token</kw>
            <kw>Refresh Token</kw>
            <kw>Authorization Code</kw>
            <kw>Implicit Grant</kw>
            <kw>Client Identifier</kw>
            <kw>Access Token Scope</kw>
            <kw>Delegation</kw>
        </keywords>
        <abstract><p>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-oauth-v2-31</draft>
        <obsoletes>
            <doc-id>RFC5849</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8252</doc-id>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9700</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6749</errata-url>
        <doi>10.17487/RFC6749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6750</doc-id>
        <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>D. Hardt</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Client</kw>
            <kw>Resource Owner</kw>
            <kw>Authorization Server</kw>
            <kw>Resource Server, Token Endpoint</kw>
            <kw>Authorization Endpoint</kw>
            <kw>Authorization Request, Authorization Grant</kw>
            <kw>Protected Resource</kw>
            <kw>Access Token</kw>
            <kw>Refresh Token</kw>
            <kw>Authorization Code</kw>
            <kw>Implicit Grant</kw>
            <kw>Client Identifier, Access Token Scope</kw>
            <kw>Bearer Authorization Header</kw>
            <kw>Bearer Access Token Type</kw>
        </keywords>
        <abstract><p>This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources.  Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-oauth-v2-bearer-23</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
            <doc-id>RFC9700</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6750</errata-url>
        <doi>10.17487/RFC6750</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6751</doc-id>
        <title>Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)</title>
        <author>
            <name>R. Despres</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Coexistence</kw>
            <kw>Transition</kw>
            <kw>Interworking</kw>
            <kw>Tunneling</kw>
            <kw>Encapsulation</kw>
            <kw>Mapping</kw>
            <kw>map-and-encap</kw>
            <kw>Global Addressing</kw>
        </keywords>
        <abstract><p>In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity.  However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types).  6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations.  At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)).  The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-despres-6a44-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6751</errata-url>
        <doi>10.17487/RFC6751</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6752</doc-id>
        <title>Issues with Private IP Addressing in the Internet</title>
        <author>
            <name>A. Kirkham</name>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network.  The discussion focuses on link addresses and, to a small extent, loopback addresses.  While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-grow-private-ip-sp-cores-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6753</doc-id>
        <title>A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>HELD</kw>
            <kw>Dereference</kw>
            <kw>lbyr</kw>
            <kw>HTTP</kw>
            <kw>Location</kw>
            <kw>GEOPRIV</kw>
        </keywords>
        <abstract><p>This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO).  This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-deref-protocol-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6753</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6754</doc-id>
        <title>Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect</title>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>L. Wei</name>
        </author>
        <author>
            <name>H. Ou</name>
        </author>
        <author>
            <name>V. Arya</name>
        </author>
        <author>
            <name>S. Jethwani</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state.  When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path.  Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics.  This usually leads to inefficient or ineffective use of network resources.  This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs.  It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pim-ecmp-05</draft>
        <updated-by>
            <doc-id>RFC8736</doc-id>
            <doc-id>RFC9436</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6755</doc-id>
        <title>An IETF URN Sub-Namespace for OAuth</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>URN</kw>
            <kw>sub-namespace</kw>
            <kw>urn:ietf:params:oauth</kw>
        </keywords>
        <abstract><p>This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-oauth-urn-sub-ns-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC6755</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6756</doc-id>
        <title>Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines</title>
        <author>
            <name>S. Trowbridge</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Lear</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Fishman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bradner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012).</p><p> Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations.</p><p> This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-rfc3356bis-05</draft>
        <obsoletes>
            <doc-id>RFC3356</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6756</errata-url>
        <doi>10.17487/RFC6756</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6757</doc-id>
        <title>Access Network Identifier (ANI) Option for Proxy Mobile IPv6</title>
        <author>
            <name>S. Gundavelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Grayson</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ANI</kw>
            <kw>ANI option</kw>
            <kw>Access Network Identifier option</kw>
            <kw>PMIPv6 ANI option</kw>
        </keywords>
        <abstract><p>The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached.  This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-netext-access-network-option-13</draft>
        <updated-by>
            <doc-id>RFC7563</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6758</doc-id>
        <title>Tunneling of SMTP Message Transfer Priorities</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>K. Carlberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Priority</kw>
            <kw>MMHS</kw>
        </keywords>
        <abstract><p>This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-melnikov-smtp-priority-tunneling-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6759</doc-id>
        <title>Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)</title>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>N. Ben-Dvora</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-claise-export-application-info-in-ipfix-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6759</errata-url>
        <doi>10.17487/RFC6759</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6760</doc-id>
        <title>Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Krochmal</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution.  This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.</p></abstract>
        <draft>draft-cheshire-dnsext-nbp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6760</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6761</doc-id>
        <title>Special-Use Domain Names</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Krochmal</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so.  It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.</p></abstract>
        <draft>draft-cheshire-dnsext-special-names-03</draft>
        <updates>
            <doc-id>RFC1918</doc-id>
            <doc-id>RFC2606</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6761</errata-url>
        <doi>10.17487/RFC6761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6762</doc-id>
        <title>Multicast DNS</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Krochmal</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <abstract><p>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</p><p> Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</p><p> The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</p></abstract>
        <draft>draft-cheshire-dnsext-multicastdns-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6762</errata-url>
        <doi>10.17487/RFC6762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6763</doc-id>
        <title>DNS-Based Service Discovery</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Krochmal</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <abstract><p>This document specifies how DNS resource records are named and structured to facilitate service discovery.  Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries.  This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</p></abstract>
        <draft>draft-cheshire-dnsext-dns-sd-11</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6763</errata-url>
        <doi>10.17487/RFC6763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6764</doc-id>
        <title>Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SRV</kw>
            <kw>iCalendar</kw>
        </keywords>
        <abstract><p>This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.</p></abstract>
        <draft>draft-daboo-srv-caldav-10</draft>
        <updates>
            <doc-id>RFC4791</doc-id>
            <doc-id>RFC6352</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6764</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6765</doc-id>
        <title>xDSL Multi-Pair Bonding (G.Bond) MIB</title>
        <author>
            <name>E. Beili</name>
        </author>
        <author>
            <name>M. Morgenstern</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Management Information Base</kw>
            <kw>xDSL bonding</kw>
            <kw>aggregation</kw>
            <kw>G.998</kw>
            <kw>G.998.1</kw>
            <kw>G.998.2</kw>
            <kw>G.998.3</kw>
            <kw>TDIM</kw>
            <kw>IMA</kw>
            <kw>EFM</kw>
        </keywords>
        <abstract><p>This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3.  The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA).  The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.</p></abstract>
        <draft>draft-ietf-adslmib-gbond-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6765</errata-url>
        <doi>10.17487/RFC6765</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6766</doc-id>
        <title>xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB</title>
        <author>
            <name>E. Beili</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Management Information Base</kw>
            <kw>xDSL bonding</kw>
            <kw>aggregation</kw>
            <kw>G.998.3</kw>
        </keywords>
        <abstract><p>This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.</p></abstract>
        <draft>draft-ietf-adslmib-gbond-tdim-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6766</errata-url>
        <doi>10.17487/RFC6766</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6767</doc-id>
        <title>Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB</title>
        <author>
            <name>E. Beili</name>
        </author>
        <author>
            <name>M. Morgenstern</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Management Information Base</kw>
            <kw>xDSL bonding</kw>
            <kw>Ethernet bonding</kw>
            <kw>aggregation</kw>
            <kw>802.3ah</kw>
            <kw>G.998.2</kw>
        </keywords>
        <abstract><p>This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.</p></abstract>
        <draft>draft-ietf-adslmib-gbond-eth-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6767</errata-url>
        <doi>10.17487/RFC6767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6768</doc-id>
        <title>ATM-Based xDSL Bonded Interfaces MIB</title>
        <author>
            <name>E. Beili</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>SNMP</kw>
            <kw>Management Information Base</kw>
            <kw>bonding</kw>
            <kw>xDSL bonding</kw>
            <kw>aggregation</kw>
            <kw>G.Bond</kw>
            <kw>G.Bond/ATM</kw>
            <kw>G.998.1</kw>
            <kw>IMA</kw>
            <kw>IMA+</kw>
        </keywords>
        <abstract><p>This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.  This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.</p></abstract>
        <draft>draft-ietf-adslmib-gbond-atm-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>adslmib</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6768</errata-url>
        <doi>10.17487/RFC6768</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6769</doc-id>
        <title>Simple Virtual Aggregation (S-VA)</title>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>J. Heitz</name>
        </author>
        <author>
            <name>A. Lo</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <author>
            <name>X. Xu</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>aggregation</kw>
        </keywords>
        <abstract><p>All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).</p><p> Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.</p><p> The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-grow-simple-va-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6770</doc-id>
        <title>Use Cases for Content Delivery Network Interconnection</title>
        <author>
            <name>G. Bertrand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Stephan</name>
        </author>
        <author>
            <name>T. Burbridge</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>K. Ma</name>
        </author>
        <author>
            <name>G. Watson</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>CDN</kw>
            <kw>CDNI</kw>
        </keywords>
        <abstract><p>Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level.  This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented.  This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces.  It obsoletes RFC 3570.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-cdni-use-cases-10</draft>
        <obsoletes>
            <doc-id>RFC3570</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC6770</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6771</doc-id>
        <title>Considerations for Having a Successful "Bar BOF" Side Meeting</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.</p><p> During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.</p><p> This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-eggert-successful-bar-bof-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6771</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6772</doc-id>
        <title>Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information</title>
        <author>
            <name>H. Schulzrinne</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Cuellar</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Authorization Policy</kw>
            <kw>Location Privacy</kw>
        </keywords>
        <abstract><p>This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.</p><p> Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-policy-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6772</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6773</doc-id>
        <title>DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal</title>
        <author>
            <name>T. Phelan</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>DCCP</kw>
            <kw>NAPT</kw>
            <kw>NAT</kw>
            <kw>UDP</kw>
        </keywords>
        <abstract><p>This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP.  This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes.  This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dccp-udpencap-11</draft>
        <updates>
            <doc-id>RFC4340</doc-id>
            <doc-id>RFC5762</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>dccp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6773</errata-url>
        <doi>10.17487/RFC6773</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6774</doc-id>
        <title>Distribution of Diverse BGP Paths</title>
        <author>
            <name>R. Raszuk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Fernando</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.</p><p> The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.</p><p> This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge (PE) routers acting as route reflector clients. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-grow-diverse-bgp-path-dist-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC6774</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6775</doc-id>
        <title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
        <author>
            <name>Z. Shelby</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
        </keywords>
        <abstract><p>The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4.  This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation.  In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links.  IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network.  This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks.  The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6lowpan-nd-21</draft>
        <updates>
            <doc-id>RFC4944</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8505</doc-id>
            <doc-id>RFC8929</doc-id>
            <doc-id>RFC9010</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lowpan</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6775</errata-url>
        <doi>10.17487/RFC6775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6776</doc-id>
        <title>Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>RTP Control Protocol</kw>
        </keywords>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-meas-identity-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC6776</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6777</doc-id>
        <title>Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks</title>
        <author>
            <name>W. Sun</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Gao</name>
        </author>
        <author>
            <name>G. Xie</name>
        </author>
        <author>
            <name>R. Papneja</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Provisioning performance</kw>
            <kw>Performance measurement</kw>
            <kw>UNI</kw>
            <kw>Bandwidth on Demand</kw>
            <kw>performance evaluation</kw>
            <kw>Measurement methodologies</kw>
        </keywords>
        <abstract><p>When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner.  Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable.  The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure.  Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust.  This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-dpm-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6777</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6778</doc-id>
        <title>Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>tool</kw>
        </keywords>
        <abstract><p>The IETF makes heavy use of email lists to conduct its work.  Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities.  The current archive mechanism could also be made more efficient.  This memo captures the requirements for improved email list archiving and searching systems.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-sparks-genarea-mailarch-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6778</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6779</doc-id>
        <title>Definition of Managed Objects for the Neighborhood Discovery Protocol</title>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>I. Chakeres</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>Routing</kw>
            <kw>Neighbor Discovery</kw>
            <kw>MANET</kw>
        </keywords>
        <abstract><p>This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router.  The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP.  This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-manet-nhdp-mib-19</draft>
        <obsoleted-by>
            <doc-id>RFC7939</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC6779</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6780</doc-id>
        <title>RSVP ASSOCIATION Object Extensions</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>A. Narayanan</name>
        </author>
        <date>
            <month>October</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
        </keywords>
        <abstract><p>The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs).  In this context, the object is used to associate recovery LSPs with the LSP they are protecting.  This object also has broader applicability as a mechanism to associate RSVP state.  This document defines how the ASSOCIATION object can be more generally applied.  This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP).  This document updates RFC 2205, RFC 3209, and RFC 3473.  It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-assoc-ext-06</draft>
        <updates>
            <doc-id>RFC2205</doc-id>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC3473</doc-id>
            <doc-id>RFC4872</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6780</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6781</doc-id>
        <title>DNSSEC Operational Practices, Version 2</title>
        <author>
            <name>O. Kolkman</name>
        </author>
        <author>
            <name>W. Mekking</name>
        </author>
        <author>
            <name>R. Gieben</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>operational</kw>
            <kw>key rollover</kw>
        </keywords>
        <abstract><p>This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</p><p> The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</p><p> This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.</p></abstract>
        <draft>draft-ietf-dnsop-rfc4641bis-13</draft>
        <obsoletes>
            <doc-id>RFC4641</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6781</errata-url>
        <doi>10.17487/RFC6781</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6782</doc-id>
        <title>Wireline Incremental IPv6</title>
        <author>
            <name>V. Kuarsingh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Howard</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>transition</kw>
            <kw>IPv6 transition</kw>
            <kw>operator</kw>
        </keywords>
        <abstract><p>Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks.  These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out.  Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses.  The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator.  This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-v6ops-wireline-incremental-ipv6-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6782</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6783</doc-id>
        <title>Mailing Lists and Non-ASCII Addresses</title>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Mail</kw>
            <kw>internationalization</kw>
            <kw>mailing lists</kw>
        </keywords>
        <abstract><p>This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses.  It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice.  This document is a product of the Internet Engineering Task Force (IETF).</p></abstract>
        <draft>draft-ietf-eai-mailinglistbis-05</draft>
        <obsoletes>
            <doc-id>RFC5983</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC6783</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6784</doc-id>
        <title>Kerberos Options for DHCPv6</title>
        <author>
            <name>S. Sakane</name>
        </author>
        <author>
            <name>M. Ishiyama</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>security</kw>
            <kw>dhcpv6</kw>
        </keywords>
        <abstract><p>This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-sakane-dhc-dhcpv6-kdc-option-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6784</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6785</doc-id>
        <title>Support for Internet Message Access Protocol (IMAP) Events in Sieve</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>email</kw>
            <kw>filtering</kw>
        </keywords>
        <abstract><p>Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message.  As defined in the base specification, it plugs into mail delivery.  This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).  Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sieve-imap-sieve-09</draft>
        <updates>
            <doc-id>RFC5228</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>sieve</wg_acronym>
        <doi>10.17487/RFC6785</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6786</doc-id>
        <title>Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs</title>
        <author>
            <name>A. Yegin</name>
        </author>
        <author>
            <name>R. Cragie</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-yegin-pana-encr-avp-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6786</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6787</doc-id>
        <title>Media Resource Control Protocol Version 2 (MRCPv2)</title>
        <author>
            <name>D. Burnett</name>
        </author>
        <author>
            <name>S. Shanmugham</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>224</page-count>
        <keywords>
            <kw>mrcp</kw>
            <kw>speechsc</kw>
            <kw>asr</kw>
            <kw>tts</kw>
            <kw>speech services</kw>
            <kw>speech recognition</kw>
            <kw>speech synthesis</kw>
            <kw>nlsml</kw>
            <kw>speaker authentication</kw>
            <kw>speaker verification</kw>
            <kw>speaker identification</kw>
        </keywords>
        <abstract><p>The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network.  MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities.  It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server.  Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-speechsc-mrcpv2-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>speechsc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6787</errata-url>
        <doi>10.17487/RFC6787</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6788</doc-id>
        <title>The Line-Identification Option</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>A. Kavanagh</name>
        </author>
        <author>
            <name>B. Varga</name>
        </author>
        <author>
            <name>S. Ooghe</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
        </keywords>
        <abstract><p>In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router.  This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages.  The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-6man-lineid-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6788</errata-url>
        <doi>10.17487/RFC6788</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6789</doc-id>
        <title>Congestion Exposure (ConEx) Concepts and Use Cases</title>
        <author>
            <name>B. Briscoe</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Woundy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Cooper</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Congestion Signaling</kw>
            <kw>Traffic Management</kw>
        </keywords>
        <abstract><p>This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol.  It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes.  Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-conex-concepts-uses-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>conex</wg_acronym>
        <doi>10.17487/RFC6789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6790</doc-id>
        <title>The Use of Entropy Labels in MPLS Forwarding</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>entropy</kw>
            <kw>hash</kw>
            <kw>ecmp</kw>
            <kw>load balancing</kw>
        </keywords>
        <abstract><p>Load balancing is a powerful tool for engineering traffic across a network.  This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels".  It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications.  This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-entropy-label-06</draft>
        <updates>
            <doc-id>RFC3031</doc-id>
            <doc-id>RFC3107</doc-id>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC5036</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7274</doc-id>
            <doc-id>RFC7447</doc-id>
            <doc-id>RFC8012</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6790</errata-url>
        <doi>10.17487/RFC6790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6791</doc-id>
        <title>Stateless Source Address Mapping for ICMPv6 Packets</title>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>R. Vaithianathan</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IP/ICMP Translation Algorithm</kw>
            <kw>IPv4-translatable IPv6 addresses</kw>
            <kw>ICMPv6</kw>
            <kw>traceroute</kw>
        </keywords>
        <abstract><p>A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source.  These packets should be passed across the translator as ICMP packets directed to the IPv4 destination.  This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-v6ops-ivi-icmp-address-07</draft>
        <updates>
            <doc-id>RFC6145</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6791</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6792</doc-id>
        <title>Guidelines for Use of the RTP Monitoring Framework</title>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Hunt</name>
        </author>
        <author>
            <name>P. Arden</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Real Time Control Protocol</kw>
        </keywords>
        <abstract><p>This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality.  In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application.  Applications may then "mix and match" to create a set of blocks that cover their set of concerns.  Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-avtcore-monarch-22</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6793</doc-id>
        <title>BGP Support for Four-Octet Autonomous System (AS) Number Space</title>
        <author>
            <name>Q. Vohra</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>autonomous system</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>The Autonomous System number is encoded as a two-octet entity in the base BGP specification.  This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities.  This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-idr-rfc4893bis-07</draft>
        <obsoletes>
            <doc-id>RFC4893</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6793</errata-url>
        <doi>10.17487/RFC6793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6794</doc-id>
        <title>A Framework for Session Initiation Protocol (SIP) Session Policies</title>
        <author>
            <name>V. Hilt</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
        </keywords>
        <abstract><p>Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features.  This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used.  It defines a model, an overall architecture and new protocol mechanisms for session policies. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sip-session-policy-framework-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sip</wg_acronym>
        <doi>10.17487/RFC6794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6795</doc-id>
        <title>A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies</title>
        <author>
            <name>V. Hilt</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
        </keywords>
        <abstract><p>This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies.  This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipping-policy-package-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipping</wg_acronym>
        <doi>10.17487/RFC6795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6796</doc-id>
        <title>A User Agent Profile Data Set for Media Policy</title>
        <author>
            <name>V. Hilt</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>D. Worley</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Policy</kw>
            <kw>Data Set</kw>
        </keywords>
        <abstract><p>This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions.  Examples for media properties are the codecs or media types used in the session.  This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-camarillo-rai-media-policy-dataset-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6796</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6797</doc-id>
        <title>HTTP Strict Transport Security (HSTS)</title>
        <author>
            <name>J. Hodges</name>
        </author>
        <author>
            <name>C. Jackson</name>
        </author>
        <author>
            <name>A. Barth</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>HTTPS</kw>
            <kw>TLS</kw>
            <kw>SSL</kw>
            <kw>ForceHTTPS</kw>
            <kw>man-in-the-middle</kw>
            <kw>MITM</kw>
            <kw>certificate error</kw>
            <kw>certificate verification</kw>
            <kw>security policy</kw>
            <kw>secure transport</kw>
            <kw>IDNA-Canonicalization</kw>
        </keywords>
        <abstract><p>This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.  This overall policy is referred to as HTTP Strict Transport Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-websec-strict-transport-sec-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>websec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6797</errata-url>
        <doi>10.17487/RFC6797</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6798</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-pdv-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC6798</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6799</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6800</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6801</doc-id>
        <title>Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework</title>
        <author>
            <name>U. Kozat</name>
        </author>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework.  The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-fecframe-pseudo-cdp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6801</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6802</doc-id>
        <title>Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets</title>
        <author>
            <name>S. Baillargeon</name>
        </author>
        <author>
            <name>C. Flinta</name>
        </author>
        <author>
            <name>A. Johnsson</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>available capacity</kw>
            <kw>rate</kw>
            <kw>train</kw>
            <kw>interval</kw>
            <kw>padding</kw>
            <kw>buffer</kw>
            <kw>test session</kw>
        </keywords>
        <abstract><p>This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP).  Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ippm-twamp-value-added-octets-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6802</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6803</doc-id>
        <title>Camellia Encryption for Kerberos 5</title>
        <author>
            <name>G. Hudson</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Camellia</kw>
            <kw>Kerberos</kw>
        </keywords>
        <abstract><p>This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961.  The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-krb-wg-camellia-cts-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6803</errata-url>
        <doi>10.17487/RFC6803</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6804</doc-id>
        <title>DISCOVER: Supporting Multicast DNS Queries</title>
        <author>
            <name>B. Manning</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery.  This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project.  This project is no longer active and there are no current plans to restart it.  TBDS was the first known use of multicast transport for DNS.  A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.  This document defines a Historic Document for the Internet community.</p></abstract>
        <draft>draft-manning-opcode-discover-07</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6804</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6805</doc-id>
        <title>The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS</title>
        <author>
            <name>D. King</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.</p><p> Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.</p><p> This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-pce-hierarchy-fwk-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC6805</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6806</doc-id>
        <title>Kerberos Principal Name Canonicalization and Cross-Realm Referrals</title>
        <author>
            <name>S. Hartman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Raeburn</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>security protocols</kw>
            <kw>identity</kw>
        </keywords>
        <abstract><p>This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services.  The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path.  The clients will use this referral information to reach the realm of the target principal and then receive the ticket.  This memo also provides a mechanism for verifying that a request has not been tampered with in transit.  This memo updates RFC 4120. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-krb-wg-kerberos-referrals-15</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6806</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6807</doc-id>
        <title>Population Count Extensions to Protocol Independent Multicast (PIM)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>G. Shepherd</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>Y. Cai</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This specification defines a method for providing multicast distribution-tree accounting data.  Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-pim-pop-count-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC6807</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6808</doc-id>
        <title>Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track</title>
        <author>
            <name>L. Ciavattone</name>
        </author>
        <author>
            <name>R. Geib</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>M. Wieser</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>One-way Delay</kw>
            <kw>IP Performance Metrics</kw>
            <kw>IPPM</kw>
        </keywords>
        <abstract><p>This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576.  Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended.  Two completely independent implementations have been tested against the key specifications of RFC 2679.  This memo also provides direct input for development of a revision of RFC 2679.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-ippm-testplan-rfc2679-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC6808</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6809</doc-id>
        <title>Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>I. Sedlacek</name>
        </author>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>proxy</kw>
            <kw>feature</kw>
            <kw>feature tag</kw>
            <kw>feature-capability indicator</kw>
            <kw>Feature-Caps</kw>
            <kw>capability</kw>
        </keywords>
        <abstract><p>This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.</p><p> SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.</p><p> This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sipcore-proxy-feature-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC6809</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6810</doc-id>
        <title>The Resource Public Key Infrastructure (RPKI) to Router Protocol</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
        </keywords>
        <abstract><p>In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache.  This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-rpki-rtr-26</draft>
        <updated-by>
            <doc-id>RFC8210</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6810</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6811</doc-id>
        <title>BGP Prefix Origin Validation</title>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SIDR</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes.  More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so.  This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-sidr-pfx-validate-10</draft>
        <updated-by>
            <doc-id>RFC8481</doc-id>
            <doc-id>RFC8893</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6811</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6812</doc-id>
        <title>Cisco Service-Level Assurance Protocol</title>
        <author>
            <name>M. Chiba</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>S. Medley</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>S. Thombare</name>
        </author>
        <author>
            <name>E. Yedavalli</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Cisco's SLA Protocol</kw>
        </keywords>
        <abstract><p>Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance Measurement protocol that has been widely deployed.  The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss.  This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-cisco-sla-protocol-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6812</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6813</doc-id>
        <title>The Network Endpoint Assessment (NEA) Asokan Attack Analysis</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>S. Hanna</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Man-in-the-Middle</kw>
            <kw>MITM</kw>
            <kw>Security</kw>
            <kw>Endpoint</kw>
            <kw>Posture</kw>
            <kw>Protocol</kw>
            <kw>Forwarding</kw>
            <kw>TNC</kw>
            <kw>Channel</kw>
            <kw>Binding</kw>
            <kw>Cryptographic</kw>
            <kw>Countermeasure</kw>
        </keywords>
        <abstract><p>The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack.  This document describes the attack and countermeasures that may be mounted.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-nea-asokan-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>nea</wg_acronym>
        <doi>10.17487/RFC6813</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6814</doc-id>
        <title>Formally Deprecating Some IPv4 Options</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
        </keywords>
        <abstract><p>A number of IPv4 options have become obsolete in practice, but have never been formally deprecated.  This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry.  Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-gp-intarea-obsolete-ipv4-options-iana-02</draft>
        <obsoletes>
            <doc-id>RFC1385</doc-id>
            <doc-id>RFC1393</doc-id>
            <doc-id>RFC1475</doc-id>
            <doc-id>RFC1770</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6814</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6815</doc-id>
        <title>Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>K. Dubray</name>
        </author>
        <author>
            <name>J. McQuaid</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>November</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>testing</kw>
            <kw>performance</kw>
        </keywords>
        <abstract><p>The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present.  The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity.  Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods.  This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-bmwg-2544-as-08</draft>
        <updates>
            <doc-id>RFC2544</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6815</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6816</doc-id>
        <title>Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>M. Cunche</name>
        </author>
        <author>
            <name>J. Lacan</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Forward Error Correction</kw>
            <kw>LDPC-Staircase</kw>
        </keywords>
        <abstract><p>This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME.  These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs.  LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance.  They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.</p></abstract>
        <draft>draft-ietf-fecframe-ldpc-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6816</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6817</doc-id>
        <title>Low Extra Delay Background Transport (LEDBAT)</title>
        <author>
            <name>S. Shalunov</name>
        </author>
        <author>
            <name>G. Hazel</name>
        </author>
        <author>
            <name>J. Iyengar</name>
        </author>
        <author>
            <name>M. Kuehlewind</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Congestion control</kw>
            <kw>delay-based</kw>
            <kw>scavenger</kw>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path.  LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network.  LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-ledbat-congestion-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ledbat</wg_acronym>
        <doi>10.17487/RFC6817</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6818</doc-id>
        <title>Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>P. Yee</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".  This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII.  This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-rfc5280-clarifications-11</draft>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <doi>10.17487/RFC6818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6819</doc-id>
        <title>OAuth 2.0 Threat Model and Security Considerations</title>
        <author>
            <name>T. Lodderstedt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. McGloin</name>
        </author>
        <author>
            <name>P. Hunt</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>authorization</kw>
            <kw>authentication</kw>
            <kw>token</kw>
            <kw>counter-measures</kw>
            <kw>HTTP</kw>
            <kw>REST</kw>
        </keywords>
        <abstract><p>This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-oauth-v2-threatmodel-08</draft>
        <updated-by>
            <doc-id>RFC9700</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6819</errata-url>
        <doi>10.17487/RFC6819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6820</doc-id>
        <title>Address Resolution Problems in Large Data Center Networks</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>M. Karir</name>
        </author>
        <author>
            <name>I. Foo</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ARMD</kw>
            <kw>data center</kw>
            <kw>ARP</kw>
            <kw>ND</kw>
            <kw>Neighbor Discovery</kw>
        </keywords>
        <abstract><p>This document examines address resolution issues related to the scaling of data centers with a very large number of hosts.  The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center.  This document is a product of the Internet Engineering Task Force (IETF).</p></abstract>
        <draft>draft-ietf-armd-problem-statement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>armd</wg_acronym>
        <doi>10.17487/RFC6820</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6821</doc-id>
        <title>Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality</title>
        <author>
            <name>E. Marocco</name>
        </author>
        <author>
            <name>A. Fusco</name>
        </author>
        <author>
            <name>I. Rimac</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>cross-domain traffic</kw>
            <kw>bandwidth</kw>
            <kw>transit traffic</kw>
            <kw>peer-to-peer caching</kw>
            <kw>peer-to-peer swarm</kw>
        </keywords>
        <abstract><p>Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.</p><p> This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).</p></abstract>
        <draft>draft-irtf-p2prg-mythbustering-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6821</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6822</doc-id>
        <title>IS-IS Multi-Instance</title>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
        </keywords>
        <abstract><p>This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.</p><p> Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.</p></abstract>
        <draft>draft-ietf-isis-mi-08</draft>
        <obsoleted-by>
            <doc-id>RFC8202</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6822</errata-url>
        <doi>10.17487/RFC6822</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6823</doc-id>
        <title>Advertising Generic Information in IS-IS</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <date>
            <month>December</month>
            <year>2012</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>intermediate system to intermediate system</kw>
        </keywords>
        <abstract><p>This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.</p></abstract>
        <draft>draft-ietf-isis-genapp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC6823</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6824</doc-id>
        <title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
        <author>
            <name>A. Ford</name>
        </author>
        <author>
            <name>C. Raiciu</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</p><p> Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-mptcp-multiaddressed-12</draft>
        <obsoleted-by>
            <doc-id>RFC8684</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6824</errata-url>
        <doi>10.17487/RFC6824</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6825</doc-id>
        <title>Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS</title>
        <author>
            <name>M. Miyazawa</name>
        </author>
        <author>
            <name>T. Otani</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>TED-MIB</kw>
            <kw>ted</kw>
            <kw>mib</kw>
        </keywords>
        <abstract><p>This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ted-mib-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6826</doc-id>
        <title>Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>M. Napierala</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
        </keywords>
        <abstract><p>Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created.  The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP.  When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages.  When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain.  The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP.  This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-mldp-in-band-signaling-08</draft>
        <updated-by>
            <doc-id>RFC7438</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6826</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6827</doc-id>
        <title>Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols</title>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Papadimitriou</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
        </keywords>
        <abstract><p>The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).</p><p> The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.</p><p> The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.</p><p> Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ccamp-rfc5787bis-06</draft>
        <obsoletes>
            <doc-id>RFC5787</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5786</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6827</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6828</doc-id>
        <title>Content Splicing for RTP Sessions</title>
        <author>
            <name>J. Xia</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.</p><p> This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-avtext-splicing-for-rtp-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC6828</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6829</doc-id>
        <title>Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6</title>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>P. Pan</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
        </keywords>
        <abstract><p>The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.</p><p> This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-mpls-ipv6-pw-lsp-ping-04</draft>
        <obsoleted-by>
            <doc-id>RFC8029</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4379</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6829</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6830</doc-id>
        <title>The Locator/ID Separation Protocol (LISP)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>75</page-count>
        <abstract><p>This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.</p><p> Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-lisp-24</draft>
        <obsoleted-by>
            <doc-id>RFC9300</doc-id>
            <doc-id>RFC9301</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8113</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6830</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6831</doc-id>
        <title>The Locator/ID Separation Protocol (LISP) for Multicast Environments</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>J. Zwiebel</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-lisp-multicast-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6831</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6832</doc-id>
        <title>Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites</title>
        <author>
            <name>D. Lewis</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP.  A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive.  While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites.  This document introduces three such mechanisms.  The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts.  Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs.  Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-lisp-interworking-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6832</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6833</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Map-Server Interface</title>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.</p><p> By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-lisp-ms-16</draft>
        <obsoleted-by>
            <doc-id>RFC9301</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6833</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6834</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Map-Versioning</title>
        <author>
            <name>L. Iannone</name>
        </author>
        <author>
            <name>D. Saucez</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets.  The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets.  LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets.  The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-lisp-map-versioning-09</draft>
        <obsoleted-by>
            <doc-id>RFC9302</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6834</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6835</doc-id>
        <title>The Locator/ID Separation Protocol Internet Groper (LIG)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database.  This document describes how it works.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-lisp-lig-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6835</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6836</doc-id>
        <title>Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)</title>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID).  The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID.  Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE).  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-ietf-lisp-alt-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC6836</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6837</doc-id>
        <title>NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database</title>
        <author>
            <name>E. Lear</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another.  This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner.  Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-lear-lisp-nerd-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6837</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6838</doc-id>
        <title>Media Type Specifications and Registration Procedures</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-ietf-appsawg-media-type-regs-14</draft>
        <obsoletes>
            <doc-id>RFC4288</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9694</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>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC6838</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6839</doc-id>
        <title>Additional Media Type Structured Syntax Suffixes</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>structured syntax suffix</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name.  This document defines several structured syntax suffixes for use with media type registrations.  In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-appsawg-media-type-suffix-regs-08</draft>
        <updates>
            <doc-id>RFC3023</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7303</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6839</errata-url>
        <doi>10.17487/RFC6839</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6840</doc-id>
        <title>Clarifications and Implementation Notes for DNS Security (DNSSEC)</title>
        <author>
            <name>S. Weiler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Blacka</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>AAA</kw>
            <kw>reconnect</kw>
        </keywords>
        <abstract><p>This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.</p><p> This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-bis-updates-20</draft>
        <updates>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC5155</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8749</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6840</errata-url>
        <doi>10.17487/RFC6840</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6841</doc-id>
        <title>A Framework for DNSSEC Policies and DNSSEC Practice Statements</title>
        <author>
            <name>F. Ljunggren</name>
        </author>
        <author>
            <name>AM. Eklund Lowinder</name>
        </author>
        <author>
            <name>T. Okubo</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>DP</kw>
            <kw>DPS</kw>
        </keywords>
        <abstract><p>This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.</p><p> In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-dps-framework-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC6841</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6842</doc-id>
        <title>Client Identifier Option in DHCP Server Replies</title>
        <author>
            <name>N. Swamy</name>
        </author>
        <author>
            <name>G. Halwasia</name>
        </author>
        <author>
            <name>P. Jhingran</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-dhc-client-id-07</draft>
        <updates>
            <doc-id>RFC2131</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6842</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6843</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>K. Gross</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Round Trip Delay</kw>
            <kw>End System Delay</kw>
        </keywords>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-delay-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC6843</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6844</doc-id>
        <title>DNS Certification Authority Authorization (CAA) Resource Record</title>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <author>
            <name>R. Stradling</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>PKIX</kw>
        </keywords>
        <abstract><p>The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain.  CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.  This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-pkix-caa-15</draft>
        <obsoleted-by>
            <doc-id>RFC8659</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6844</errata-url>
        <doi>10.17487/RFC6844</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6845</doc-id>
        <title>OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type</title>
        <author>
            <name>N. Sheth</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>P2MP</kw>
            <kw>Broadcast</kw>
            <kw>Interface</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.</p><p> This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-hybrid-bcast-and-p2mp-06</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
            <doc-id>RFC5340</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC6845</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6846</doc-id>
        <title>RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)</title>
        <author>
            <name>G. Pelletier</name>
        </author>
        <author>
            <name>K. Sandlund</name>
        </author>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>M. West</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
        </keywords>
        <abstract><p>This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.</p><p> ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.</p><p> This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-sandlund-rfc4996bis-02</draft>
        <obsoletes>
            <doc-id>RFC4996</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6846</errata-url>
        <doi>10.17487/RFC6846</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6847</doc-id>
        <title>Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>D. Melman</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>FCoE</kw>
            <kw>FCRB</kw>
            <kw>TRILL</kw>
            <kw>RBridge</kw>
        </keywords>
        <abstract><p>Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment.  While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop.  This document describes an architecture for the integrated deployment of these two protocols.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-mme-trill-fcoe-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6847</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6848</doc-id>
        <title>Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>R. George</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Extension</kw>
            <kw>Local</kw>
            <kw>Civic</kw>
            <kw>Location</kw>
            <kw>GEOPRIV</kw>
        </keywords>
        <abstract><p>New fields are occasionally added to civic addresses.  A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described.  A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation.  Initial extensions for some new elements are also defined.  The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-geopriv-local-civic-10</draft>
        <updates>
            <doc-id>RFC4776</doc-id>
            <doc-id>RFC5222</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6848</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6849</doc-id>
        <title>An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback</title>
        <author>
            <name>H. Kaplan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Hedayat</name>
        </author>
        <author>
            <name>N. Venna</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>N. Stratton</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>multimedia</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>RTCP</kw>
            <kw>diagnostic</kw>
            <kw>voip</kw>
        </keywords>
        <abstract><p>The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance.  In particular, media delivery is an area that needs attention.  One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter.  This is typically referred to as "active monitoring" of services.  Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real-time text, or Video over IP service.  Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service.  The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter.  Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.</p></abstract>
        <draft>draft-ietf-mmusic-media-loopback-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC6849</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6850</doc-id>
        <title>Definitions of Managed Objects for Routing Bridges (RBridges)</title>
        <author>
            <name>A. Rijhsinghani</name>
        </author>
        <author>
            <name>K. Zebrose</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it defines objects for managing a Routing Bridge (RBridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-trill-rbridge-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC6850</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6851</doc-id>
        <title>Internet Message Access Protocol (IMAP) - MOVE Extension</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <author>
            <name>N. Freed</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IMAP</kw>
        </keywords>
        <abstract><p>This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-imapmove-command-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>imapmove</wg_acronym>
        <doi>10.17487/RFC6851</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6852</doc-id>
        <title>Affirmation of the Modern Paradigm for Standards</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Mills</name>
        </author>
        <author>
            <name>J. Jaffe</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>L. St.Amour</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards.  These principles have become known as the "OpenStand" principles.  This document contains the text of the affirmation that was signed.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-iab-modern-paradigm-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6852</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6853</doc-id>
        <title>DHCPv6 Redundancy Deployment Considerations</title>
        <author>
            <name>J. Brzozowski</name>
        </author>
        <author>
            <name>J. Tremblay</name>
        </author>
        <author>
            <name>J. Chen</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Redundancy</kw>
            <kw>Deployment Considerations</kw>
        </keywords>
        <abstract><p>This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6.  In particular, it discusses the provision of semi-redundant DHCPv6 services.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-redundancy-consider-03</draft>
        <is-also>
            <doc-id>BCP0180</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6853</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6854</doc-id>
        <title>Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:".  This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.</p></abstract>
        <draft>draft-leiba-5322upd-from-group-09</draft>
        <updates>
            <doc-id>RFC5322</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6854</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6855</doc-id>
        <title>IMAP Support for UTF-8</title>
        <author>
            <name>P. Resnick</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Newman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Shen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>IDNA</kw>
        </keywords>
        <abstract><p>This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.  This specification replaces RFC 5738.</p></abstract>
        <draft>draft-ietf-eai-5738bis-12</draft>
        <obsoletes>
            <doc-id>RFC5738</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9755</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6855</errata-url>
        <doi>10.17487/RFC6855</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6856</doc-id>
        <title>Post Office Protocol Version 3 (POP3) Support for UTF-8</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>J. Yao</name>
        </author>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>internationalized</kw>
        </keywords>
        <abstract><p>This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.</p></abstract>
        <draft>draft-ietf-eai-rfc5721bis-08</draft>
        <obsoletes>
            <doc-id>RFC5721</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC6856</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6857</doc-id>
        <title>Post-Delivery Message Downgrading for Internationalized Email Messages</title>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>Email Address Internationalization</kw>
            <kw>Downgrade</kw>
            <kw>MAIL</kw>
        </keywords>
        <abstract><p>The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields.  Upgraded POP and IMAP servers support internationalized messages.  If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message.  To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format.  As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.</p></abstract>
        <draft>draft-ietf-eai-popimap-downgrade-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6857</errata-url>
        <doi>10.17487/RFC6857</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6858</doc-id>
        <title>Simplified POP and IMAP Downgrading for Internationalized Email</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients.  The specification is simple, easy to implement, and provides only rudimentary results.</p></abstract>
        <draft>draft-ietf-eai-simpledowngrade-07</draft>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eai</wg_acronym>
        <doi>10.17487/RFC6858</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6859</doc-id>
        <title>Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>nomcom</kw>
            <kw>IAOC</kw>
        </keywords>
        <abstract><p>RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee".  Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777.  There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members".  This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC.  This memo documents an Internet Best Current Practice.</p></abstract>
        <draft>draft-leiba-3777upd-eligibility-06</draft>
        <obsoleted-by>
            <doc-id>RFC7437</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3777</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6859</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6860</doc-id>
        <title>Hiding Transit-Only Networks in OSPF</title>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
        </keywords>
        <abstract><p>A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.</p><p> In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.</p><p> This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-ospf-prefix-hiding-07</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
            <doc-id>RFC5340</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6860</errata-url>
        <doi>10.17487/RFC6860</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6861</doc-id>
        <title>The "create-form" and "edit-form" Link Relations</title>
        <author>
            <name>I. Dzmanashvili</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>RFC 5988 standardized a means of indicating the relationships between resources on the Web.  This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</p></abstract>
        <draft>draft-ioseb-dzmanashvili-link-relation-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6861</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6862</doc-id>
        <title>Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements</title>
        <author>
            <name>G. Lebovitz</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>Different routing protocols employ different mechanisms for securing protocol packets on the wire.  While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated.  The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms.  This document does not contain protocol specifications.  Instead, it defines the areas where protocol specification work is needed.  This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.</p></abstract>
        <draft>draft-ietf-karp-threats-reqs-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>karp</wg_acronym>
        <doi>10.17487/RFC6862</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6863</doc-id>
        <title>Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518).  Key components of solutions to gaps identified in this document are already underway.</p></abstract>
        <draft>draft-ietf-karp-ospf-analysis-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>karp</wg_acronym>
        <doi>10.17487/RFC6863</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6864</doc-id>
        <title>Updated Specification of the IPv4 ID Field</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple.  If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes.  Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification.  This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented.  It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]</p></abstract>
        <draft>draft-ietf-intarea-ipv4-id-update-07</draft>
        <updates>
            <doc-id>RFC0791</doc-id>
            <doc-id>RFC1122</doc-id>
            <doc-id>RFC2003</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC6864</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6865</doc-id>
        <title>Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>M. Cunche</name>
        </author>
        <author>
            <name>J. Lacan</name>
        </author>
        <author>
            <name>A. Bouabdallah</name>
        </author>
        <author>
            <name>K. Matsuzono</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Forward Error Correction</kw>
            <kw>Reed-Solomon</kw>
        </keywords>
        <abstract><p>This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 &lt;= m &lt;= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME.  The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding.  However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.</p></abstract>
        <draft>draft-ietf-fecframe-simple-rs-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>fecframe</wg_acronym>
        <doi>10.17487/RFC6865</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6866</doc-id>
        <title>Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.</p></abstract>
        <draft>draft-ietf-6renum-static-problem-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>6renum</wg_acronym>
        <doi>10.17487/RFC6866</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6867</doc-id>
        <title>An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>January</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996.  This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696.  This document defines an Experimental Protocol for the Internet community.</p></abstract>
        <draft>draft-nir-ipsecme-erx-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6867</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6868</doc-id>
        <title>Parameter Value Encoding in iCalendar and vCard</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>calendar</kw>
            <kw>contact</kw>
        </keywords>
        <abstract><p>This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.</p></abstract>
        <draft>draft-daboo-ical-vcard-parameter-encoding-04</draft>
        <updates>
            <doc-id>RFC5545</doc-id>
            <doc-id>RFC6321</doc-id>
            <doc-id>RFC6350</doc-id>
            <doc-id>RFC6351</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6868</errata-url>
        <doi>10.17487/RFC6868</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6869</doc-id>
        <title>vCard KIND:device</title>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>J. Clarke</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>vCard</kw>
        </keywords>
        <abstract><p>This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]</p></abstract>
        <draft>draft-salgueiro-vcarddav-kind-device-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6869</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6870</doc-id>
        <title>Pseudowire Preferential Forwarding Status Bit</title>
        <author>
            <name>P. Muley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Aissaoui</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>PW redundancy</kw>
            <kw>active PW</kw>
            <kw>standby PW</kw>
            <kw>primary PW</kw>
            <kw>secondary PW</kw>
            <kw>PW precedence</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications.</p><p> In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.</p><p> In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.</p><p> Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.</p></abstract>
        <draft>draft-ietf-pwe3-redundancy-bit-09</draft>
        <updates>
            <doc-id>RFC4447</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7771</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6870</errata-url>
        <doi>10.17487/RFC6870</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6871</doc-id>
        <title>Session Description Protocol (SDP) Media Capabilities Negotiation</title>
        <author>
            <name>R. Gilman</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>Session Capabilities</kw>
            <kw>Latent Configurations</kw>
            <kw>Media Format Capability</kw>
        </keywords>
        <abstract><p>Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.</p><p> This document updates the IANA Considerations of RFC 5939.</p></abstract>
        <draft>draft-ietf-mmusic-sdp-media-capabilities-17</draft>
        <updates>
            <doc-id>RFC5939</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC6871</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6872</doc-id>
        <title>The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model</title>
        <author>
            <name>V. Gurbani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Burger</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Anjali</name>
        </author>
        <author>
            <name>H. Abdelnur</name>
        </author>
        <author>
            <name>O. Festor</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>logging</kw>
            <kw>analytics</kw>
            <kw>information model</kw>
        </keywords>
        <abstract><p>Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format.  The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends.  Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system.  The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection.  This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.</p></abstract>
        <draft>draft-ietf-sipclf-problem-statement-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipclf</wg_acronym>
        <doi>10.17487/RFC6872</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6873</doc-id>
        <title>Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)</title>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>SIPCLF</kw>
        </keywords>
        <abstract><p>The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers.  This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid.  This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation.  This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.</p></abstract>
        <draft>draft-ietf-sipclf-format-11</draft>
        <updated-by>
            <doc-id>RFC7355</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipclf</wg_acronym>
        <doi>10.17487/RFC6873</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6874</doc-id>
        <title>Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document describes how the zone identifier of an IPv6 scoped address, defined as &lt;zone_id&gt; in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address.  It updates the URI Generic Syntax specification (RFC 3986) accordingly.</p></abstract>
        <draft>draft-ietf-6man-uri-zoneid-06</draft>
        <updates>
            <doc-id>RFC3986</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6874</errata-url>
        <doi>10.17487/RFC6874</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6875</doc-id>
        <title>The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan</title>
        <author>
            <name>S. Kamei</name>
        </author>
        <author>
            <name>T. Momose</name>
        </author>
        <author>
            <name>T. Inoue</name>
        </author>
        <author>
            <name>T. Nishitani</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>overlay network</kw>
            <kw>content delivery network</kw>
            <kw>peer-to-peer</kw>
            <kw>traffic engineering</kw>
            <kw>experiments in Japan</kw>
        </keywords>
        <abstract><p>This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic.  These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure.  Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.</p></abstract>
        <draft>draft-kamei-p2p-experiments-japan-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC6875</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6876</doc-id>
        <title>A Posture Transport Protocol over TLS (PT-TLS)</title>
        <author>
            <name>P. Sangster</name>
        </author>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Network Endpoint Assessment</kw>
            <kw>NEA</kw>
        </keywords>
        <abstract><p>This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol.  The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.</p></abstract>
        <draft>draft-ietf-nea-pt-tls-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>nea</wg_acronym>
        <doi>10.17487/RFC6876</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6877</doc-id>
        <title>464XLAT: Combination of Stateful and Stateless Translation</title>
        <author>
            <name>M. Mawatari</name>
        </author>
        <author>
            <name>M. Kawashima</name>
        </author>
        <author>
            <name>C. Byrne</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>XLAT</kw>
            <kw>Stateful Translation</kw>
            <kw>Stateless Translation</kw>
        </keywords>
        <abstract><p>This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge.  464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.</p></abstract>
        <draft>draft-ietf-v6ops-464xlat-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6877</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6878</doc-id>
        <title>IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field.  It updates RFC 3261.</p></abstract>
        <draft>draft-ietf-sipcore-priority-00</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6878</errata-url>
        <doi>10.17487/RFC6878</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6879</doc-id>
        <title>IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods</title>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>B. Liu</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>February</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document analyzes events that cause renumbering and describes the current renumbering methods.  These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.</p></abstract>
        <draft>draft-ietf-6renum-enterprise-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>6renum</wg_acronym>
        <doi>10.17487/RFC6879</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6880</doc-id>
        <title>An Information Model for Kerberos Version 5</title>
        <author>
            <name>L. Johansson</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>kerberos</kw>
            <kw>kdc</kw>
            <kw>LDAP</kw>
            <kw>schema</kw>
        </keywords>
        <abstract><p>This document describes an information model for Kerberos version 5 from the point of view of an administrative service.  There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC).  This document describes the services exposed by an administrative interface to a KDC.</p></abstract>
        <draft>draft-ietf-krb-wg-kdc-model-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>krb-wg</wg_acronym>
        <doi>10.17487/RFC6880</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6881</doc-id>
        <title>Best Current Practice for Communications Services in Support of Emergency Calling</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>emergency</kw>
            <kw>emergency calls</kw>
            <kw>emergency call</kw>
            <kw>emergency calling</kw>
            <kw>9-1-1</kw>
            <kw>1-1-2</kw>
            <kw>ecrit</kw>
        </keywords>
        <abstract><p>The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks.  This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.</p></abstract>
        <draft>draft-ietf-ecrit-phonebcp-20</draft>
        <updated-by>
            <doc-id>RFC7840</doc-id>
            <doc-id>RFC7852</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0181</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC6881</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6882</doc-id>
        <title>Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)</title>
        <author>
            <name>K. Kumaki</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Murai</name>
        </author>
        <author>
            <name>D. Cheng</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>P. Jiang</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.</p><p> The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.</p></abstract>
        <draft>draft-kumaki-murai-l3vpn-rsvp-te-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6882</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6883</doc-id>
        <title>IPv6 Guidance for Internet Content Providers and Application Service Providers</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers.  Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.</p></abstract>
        <draft>draft-ietf-v6ops-icp-guidance-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC6883</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6884</doc-id>
        <title>RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)</title>
        <author>
            <name>Z. Fang</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>EVRC-WB</kw>
            <kw>EVRC-B</kw>
        </keywords>
        <abstract><p>This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW).  Three media type registrations are included for EVRC-NW RTP payload formats.  In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.</p></abstract>
        <draft>draft-ietf-avt-rtp-evrc-nw-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC6884</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6885</doc-id>
        <title>Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>A. Sullivan</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow.  Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep.  Other protocols subsequently defined Stringprep profiles.  A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008).  Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed.  This document outlines the issues to be faced by those designing a Stringprep replacement.</p></abstract>
        <draft>draft-ietf-precis-problem-statement-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>precis</wg_acronym>
        <doi>10.17487/RFC6885</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6886</doc-id>
        <title>NAT Port Mapping Protocol (NAT-PMP)</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Krochmal</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings.  Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it.  From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations.  In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.</p></abstract>
        <draft>draft-cheshire-nat-pmp-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6886</errata-url>
        <doi>10.17487/RFC6886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6887</doc-id>
        <title>Port Control Protocol (PCP)</title>
        <author>
            <name>D. Wing</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>P. Selkirk</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>Firewall</kw>
        </keywords>
        <abstract><p>The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.</p></abstract>
        <draft>draft-ietf-pcp-base-29</draft>
        <updated-by>
            <doc-id>RFC7488</doc-id>
            <doc-id>RFC7652</doc-id>
            <doc-id>RFC7843</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6887</errata-url>
        <doi>10.17487/RFC6887</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6888</doc-id>
        <title>Common Requirements for Carrier-Grade NATs (CGNs)</title>
        <author>
            <name>S. Perreault</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Yamagata</name>
        </author>
        <author>
            <name>S. Miyakawa</name>
        </author>
        <author>
            <name>A. Nakagawa</name>
        </author>
        <author>
            <name>H. Ashida</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>CGN</kw>
            <kw>NAT</kw>
        </keywords>
        <abstract><p>This document defines common requirements for Carrier-Grade NATs (CGNs).  It updates RFC 4787.</p></abstract>
        <draft>draft-ietf-behave-lsn-requirements-10</draft>
        <updates>
            <doc-id>RFC4787</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0127</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC6888</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6889</doc-id>
        <title>Analysis of Stateful 64 Translation</title>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>T. Saxena</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>NAT64</kw>
            <kw>DNS64</kw>
            <kw>NAT-PT</kw>
            <kw>ALG (Application Layer Gateway)</kw>
            <kw>NAT traversal</kw>
            <kw>IPv4-IPv6 interconnection</kw>
            <kw>IPv4-IPv6 translation</kw>
        </keywords>
        <abstract><p>Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation.  Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation.  This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.</p></abstract>
        <draft>draft-ietf-behave-64-analysis-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC6889</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6890</doc-id>
        <title>Special-Purpose IP Address Registries</title>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <author>
            <name>R. Bonica</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>space assignments</kw>
        </keywords>
        <abstract><p>This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA.  It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries.  Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.</p></abstract>
        <draft>draft-bonica-special-purpose-07</draft>
        <obsoletes>
            <doc-id>RFC4773</doc-id>
            <doc-id>RFC5156</doc-id>
            <doc-id>RFC5735</doc-id>
            <doc-id>RFC5736</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8190</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0153</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6890</errata-url>
        <doi>10.17487/RFC6890</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6891</doc-id>
        <title>Extension Mechanisms for DNS (EDNS(0))</title>
        <author>
            <name>J. Damas</name>
        </author>
        <author>
            <name>M. Graff</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>DNS extensions</kw>
            <kw>domain name system</kw>
            <kw>resource records</kw>
            <kw>opt</kw>
        </keywords>
        <abstract><p>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 requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</p><p> This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</p></abstract>
        <draft>draft-ietf-dnsext-rfc2671bis-edns0-10</draft>
        <obsoletes>
            <doc-id>RFC2671</doc-id>
            <doc-id>RFC2673</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0075</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6891</errata-url>
        <doi>10.17487/RFC6891</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6892</doc-id>
        <title>The 'describes' Link Relation Type</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource.  In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.</p></abstract>
        <draft>draft-wilde-describes-link-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6892</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6893</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)</title>
        <author>
            <name>P. Higgs</name>
        </author>
        <author>
            <name>P. Szucs</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications.  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 the OIPF.</p></abstract>
        <draft>draft-higgs-oipf-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6893</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6894</doc-id>
        <title>Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection</title>
        <author>
            <name>R. Papneja</name>
        </author>
        <author>
            <name>S. Vapiwala</name>
        </author>
        <author>
            <name>J. Karthik</name>
        </author>
        <author>
            <name>S. Poretsky</name>
        </author>
        <author>
            <name>S. Rao</name>
        </author>
        <author>
            <name>JL. Le Roux</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection.  This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.</p></abstract>
        <draft>draft-ietf-bmwg-protection-meth-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6894</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6895</doc-id>
        <title>Domain Name System (DNS) IANA Considerations</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>RRTYPE</kw>
            <kw>RCODE</kw>
            <kw>AFSDB</kw>
        </keywords>
        <abstract><p>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</p></abstract>
        <draft>draft-ietf-dnsext-rfc6195bis-05</draft>
        <obsoletes>
            <doc-id>RFC6195</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1183</doc-id>
            <doc-id>RFC2845</doc-id>
            <doc-id>RFC2930</doc-id>
            <doc-id>RFC3597</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0042</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6895</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6896</doc-id>
        <title>SCS: KoanLogic's Secure Cookie Sessions for HTTP</title>
        <author>
            <name>S. Barbato</name>
        </author>
        <author>
            <name>S. Dorigotti</name>
        </author>
        <author>
            <name>T. Fossati</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>HTTP Secure Cookies</kw>
        </keywords>
        <abstract><p>This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.</p><p> Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.</p></abstract>
        <draft>draft-secure-cookie-session-protocol-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6896</errata-url>
        <doi>10.17487/RFC6896</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6897</doc-id>
        <title>Multipath TCP (MPTCP) Application Interface Considerations</title>
        <author>
            <name>M. Scharf</name>
        </author>
        <author>
            <name>A. Ford</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session.  Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit.  This document summarizes the impact that MPTCP may have on applications, such as changes in performance.  Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications.  Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.</p></abstract>
        <draft>draft-ietf-mptcp-api-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <doi>10.17487/RFC6897</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6898</doc-id>
        <title>Link Management Protocol Behavior Negotiation and Configuration Modifications</title>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>LMP</kw>
        </keywords>
        <abstract><p>The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.</p><p> This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.</p></abstract>
        <draft>draft-ietf-ccamp-lmp-behavior-negotiation-11</draft>
        <updates>
            <doc-id>RFC4204</doc-id>
            <doc-id>RFC4207</doc-id>
            <doc-id>RFC4209</doc-id>
            <doc-id>RFC5818</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC6898</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6899</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6900</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6901</doc-id>
        <title>JavaScript Object Notation (JSON) Pointer</title>
        <author>
            <name>P. Bryan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Zyp</name>
        </author>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.</p></abstract>
        <draft>draft-ietf-appsawg-json-pointer-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6901</errata-url>
        <doi>10.17487/RFC6901</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6902</doc-id>
        <title>JavaScript Object Notation (JSON) Patch</title>
        <author>
            <name>P. Bryan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method.  The "application/json-patch+json" media type is used to identify such patch documents.</p></abstract>
        <draft>draft-ietf-appsawg-json-patch-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6902</errata-url>
        <doi>10.17487/RFC6902</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6903</doc-id>
        <title>Additional Link Relation Types</title>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>http</kw>
            <kw>link</kw>
            <kw>rel</kw>
        </keywords>
        <abstract><p>This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.</p></abstract>
        <draft>draft-snell-additional-link-relations-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6903</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6904</doc-id>
        <title>Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>rtp</kw>
            <kw>header extensions</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.</p><p> This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.</p></abstract>
        <draft>draft-ietf-avtcore-srtp-encrypted-header-ext-05</draft>
        <updates>
            <doc-id>RFC3711</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC6904</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6905</doc-id>
        <title>Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>D. Bond</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>R. Watve</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks.  This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).</p></abstract>
        <draft>draft-ietf-trill-oam-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC6905</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6906</doc-id>
        <title>The 'profile' Link Relation Type</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>application profile</kw>
            <kw>profile identifier</kw>
        </keywords>
        <abstract><p>This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles.  A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.</p></abstract>
        <draft>draft-wilde-profile-link-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6906</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6907</doc-id>
        <title>Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties</title>
        <author>
            <name>T. Manderson</name>
        </author>
        <author>
            <name>K. Sriram</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Prefix origin validation</kw>
            <kw>Routing security</kw>
            <kw>BGP security</kw>
        </keywords>
        <abstract><p>This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI.  All of these items are discussed here in relation to the Internet routing system.</p></abstract>
        <draft>draft-ietf-sidr-usecases-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6907</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6908</doc-id>
        <title>Deployment Considerations for Dual-Stack Lite</title>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>R. Maglione</name>
        </author>
        <author>
            <name>C. Williams</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite).  This document describes the various deployment considerations and applicability of the DS-Lite architecture.</p></abstract>
        <draft>draft-ietf-softwire-dslite-deployment-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6908</errata-url>
        <doi>10.17487/RFC6908</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6909</doc-id>
        <title>IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6</title>
        <author>
            <name>S. Gundavelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Zhou</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>G. Feige</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6.  This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session.  Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.</p></abstract>
        <draft>draft-ietf-netext-pmipv6-sipto-option-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC6909</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6910</doc-id>
        <title>Completion of Calls for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>D. Worley</name>
        </author>
        <author>
            <name>M. Huelsemann</name>
        </author>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>D. Alexeitsev</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>call completion</kw>
            <kw>CC</kw>
            <kw>SS7</kw>
            <kw>Signaling System 7</kw>
            <kw>purpose header parameter</kw>
            <kw>m URI parameter</kw>
            <kw>m header parameter</kw>
            <kw>call-completion event package,Â CCBS</kw>
            <kw>CCNR</kw>
            <kw>CCNL</kw>
            <kw>Call-Info header field</kw>
            <kw>Presence Information Data Format</kw>
            <kw>PIDF</kw>
            <kw>P-Asserted-Identity header field</kw>
        </keywords>
        <abstract><p>The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.</p><p> For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session Initiation Protocol Service Examples" (RFC 5359).</p><p> For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.</p><p> The architecture is designed to interoperate well with existing completion of calls solutions in other networks.</p></abstract>
        <draft>draft-ietf-bliss-call-completion-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>bliss</wg_acronym>
        <doi>10.17487/RFC6910</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6911</doc-id>
        <title>RADIUS Attributes for IPv6 Access Networks</title>
        <author>
            <name>W. Dec</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Miles</name>
        </author>
        <author>
            <name>B. Lourdelet</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>RADIUS</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments.  The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.</p></abstract>
        <draft>draft-ietf-radext-ipv6-access-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC6911</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6912</doc-id>
        <title>Principles for Unicode Code Point Inclusion in Labels in the DNS</title>
        <author>
            <name>A. Sullivan</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>O. Kolkman</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points.  Most operators of zones should probably not permit registration of U-labels using the entire range.  This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root.  It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk.  This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.</p></abstract>
        <draft>draft-iab-dns-zone-codepoint-pples-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6912</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6913</doc-id>
        <title>Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>D. Hanes</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>K. Fleming</name>
        </author>
        <date>
            <month>March</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>media feature tag</kw>
        </keywords>
        <abstract><p>This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP).  Currently, fax calls are indistinguishable from voice calls at call initiation.  Consequently, fax calls can be routed to SIP user agents that are not fax capable.  A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.</p></abstract>
        <draft>draft-hanes-dispatch-fax-capability-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6913</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6914</doc-id>
        <title>SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>SIMPLE</kw>
            <kw>presence</kw>
            <kw>IM</kw>
        </keywords>
        <abstract><p>The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP).  Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE).  This document serves as a guide to the SIMPLE suite of specifications.  It categorizes the specifications, explains what each is for, and how they relate to each other.</p></abstract>
        <draft>draft-ietf-simple-simple-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC6914</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6915</doc-id>
        <title>Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)</title>
        <author>
            <name>R. Bellis</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>HELD</kw>
            <kw>Flow</kw>
        </keywords>
        <abstract><p>RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.</p><p> However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.</p><p> This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement.</p><p> This document updates RFC 6155 by deprecating the port number elements specified therein.</p></abstract>
        <draft>draft-ietf-geopriv-flow-identity-02</draft>
        <updates>
            <doc-id>RFC6155</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC6915</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6916</doc-id>
        <title>Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>R. Gagliano</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Resource Public Key Infrastructure</kw>
            <kw>RPKI</kw>
            <kw>Algorithm Transition</kw>
            <kw>SIDR</kw>
            <kw>routing security</kw>
            <kw>BGP security</kw>
        </keywords>
        <abstract><p>This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set.  The process is expected to be completed over a timescale of several years.  Consequently, no emergency transition is specified.  The transition procedure defined in this document supports only a top-down migration (parent migrates before children).</p></abstract>
        <draft>draft-ietf-sidr-algorithm-agility-12</draft>
        <is-also>
            <doc-id>BCP0182</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6916</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6917</doc-id>
        <title>Media Resource Brokering</title>
        <author>
            <name>C. Boulton</name>
        </author>
        <author>
            <name>L. Miniero</name>
        </author>
        <author>
            <name>G. Munson</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>136</page-count>
        <abstract><p>The MediaCtrl working group in the IETF has proposed an architecture for controlling media services.  The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing.  In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties.  This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers.  This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers.  The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.</p></abstract>
        <draft>draft-ietf-mediactrl-mrb-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <doi>10.17487/RFC6917</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6918</doc-id>
        <title>Formally Deprecating Some ICMPv4 Message Types</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>IPv4 Options</kw>
        </keywords>
        <abstract><p>A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated.  This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry.  Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.</p></abstract>
        <draft>draft-gp-obsolete-icmp-types-iana-01</draft>
        <obsoletes>
            <doc-id>RFC1788</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0792</doc-id>
            <doc-id>RFC0950</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6918</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6919</doc-id>
        <title>Further Key Words for Use in RFCs to Indicate Requirement Levels</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:</p><p> The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.</p></abstract>
        <draft>draft-barnes-2119bis-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6919</errata-url>
        <doi>10.17487/RFC6919</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6920</doc-id>
        <title>Naming Things with Hashes</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>D. Kutscher</name>
        </author>
        <author>
            <name>C. Dannewitz</name>
        </author>
        <author>
            <name>B. Ohlman</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Cryptography</kw>
            <kw>URI</kw>
            <kw>Information Centric Networking</kw>
        </keywords>
        <abstract><p>This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function.  It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names.  The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it.  The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.</p></abstract>
        <draft>draft-farrell-decade-ni-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6920</errata-url>
        <doi>10.17487/RFC6920</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6921</doc-id>
        <title>Design Considerations for Faster-Than-Light (FTL) Communication</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>We are approaching the time when we will be able to communicate faster than the speed of light.  It is well known that as we approach the speed of light, time slows down.  Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse.  The major consequence of this for Internet protocols is that packets will arrive before they are sent.  This will have a major impact on the way we design Internet protocols.  This paper outlines some of the issues and suggests some directions for additional analysis of these issues.</p></abstract>
        <draft>draft-hinden-FTL-design-considerations-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6921</errata-url>
        <doi>10.17487/RFC6921</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6922</doc-id>
        <title>The application/sql Media Type</title>
        <author>
            <name>Y. Shafranovich</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>SQL</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract><p>This document registers the application/sql media type to be used for the Structured Query Language (SQL).</p></abstract>
        <draft>draft-shafranovich-mime-sql-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6922</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6923</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions</title>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>M. Betts</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).  Identifiers that follow IP/MPLS conventions have already been defined.  This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).</p></abstract>
        <draft>draft-ietf-mpls-tp-itu-t-identifiers-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6923</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6924</doc-id>
        <title>Registration of Second-Level URN Namespaces under "ietf"</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces.  RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that.  But there is no registry that lists, in one place, all sub-namespaces of "ietf".  This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".</p></abstract>
        <draft>draft-leiba-urnbis-ietf-namespace-02</draft>
        <updates>
            <doc-id>RFC2648</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6924</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6925</doc-id>
        <title>The DHCPv4 Relay Agent Identifier Sub-Option</title>
        <author>
            <name>B. Joshi</name>
        </author>
        <author>
            <name>R. Desetti</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>relay</kw>
        </keywords>
        <abstract><p>This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option.  The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain.  The value is normally administratively configured in the relay agent.  The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.</p></abstract>
        <draft>draft-ietf-dhc-relay-id-suboption-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6925</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6926</doc-id>
        <title>DHCPv4 Bulk Leasequery</title>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>R. Desetti</name>
        </author>
        <author>
            <name>B. Joshi</name>
        </author>
        <author>
            <name>N. Russell</name>
        </author>
        <author>
            <name>P. Kurapati</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings.  This protocol is limited to queries for individual bindings.  In some situations, individual binding queries may not be efficient or even possible.  This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv4-bulk-leasequery-07</draft>
        <updated-by>
            <doc-id>RFC7724</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6926</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6927</doc-id>
        <title>Variants in Second-Level Names Registered in Top-Level Domains</title>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>variant</kw>
            <kw>TLDs</kw>
        </keywords>
        <abstract><p>Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS.  Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants.  This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.</p></abstract>
        <draft>draft-levine-tld-variant-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6927</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6928</doc-id>
        <title>Increasing TCP's Initial Window</title>
        <author>
            <name>J. Chu</name>
        </author>
        <author>
            <name>N. Dukkipati</name>
        </author>
        <author>
            <name>Y. Cheng</name>
        </author>
        <author>
            <name>M. Mathis</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected.  It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse.  The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.</p></abstract>
        <draft>draft-ietf-tcpm-initcwnd-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6928</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6929</doc-id>
        <title>Remote Authentication Dial In User Service (RADIUS) Protocol Extensions</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <author>
            <name>A. Lior</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <abstract><p>The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space.  In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data.  This document defines changes to RADIUS that address all of the above problems.</p></abstract>
        <draft>draft-ietf-radext-radius-extensions-13</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
            <doc-id>RFC3575</doc-id>
            <doc-id>RFC6158</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC6929</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6930</doc-id>
        <title>RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)</title>
        <author>
            <name>D. Guo</name>
        </author>
        <author>
            <name>S. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Despres</name>
        </author>
        <author>
            <name>R. Maglione</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period.  The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE).  However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol.  This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.</p></abstract>
        <draft>draft-ietf-softwire-6rd-radius-attrib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6930</errata-url>
        <doi>10.17487/RFC6930</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6931</doc-id>
        <title>Additional XML Security Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management.  These URIs identify algorithms and types of information.  This document obsoletes RFC 4051.</p></abstract>
        <draft>draft-eastlake-additional-xmlsec-uris-10</draft>
        <obsoletes>
            <doc-id>RFC4051</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9231</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6931</errata-url>
        <doi>10.17487/RFC6931</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6932</doc-id>
        <title>Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry</title>
        <author>
            <name>D. Harkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>elliptic curve</kw>
            <kw>Diffie-Hellman</kw>
        </keywords>
        <abstract><p>This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.</p></abstract>
        <draft>draft-harkins-brainpool-ike-groups-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6932</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6933</doc-id>
        <title>Entity MIB (Version 4)</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>M. Chandramouli</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract><p>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 Simple Network Management Protocol (SNMP) agent.  This document specifies version 4 of the Entity MIB.  This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.</p></abstract>
        <draft>draft-ietf-eman-rfc4133bis-06</draft>
        <obsoletes>
            <doc-id>RFC4133</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6933</errata-url>
        <doi>10.17487/RFC6933</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6934</doc-id>
        <title>Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)</title>
        <author>
            <name>N. Bitar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Wadhwa</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Haag</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs).  The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations.  The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT).  The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net.  This allows for performing access-link-related operations within those network elements to meet performance objectives.</p></abstract>
        <draft>draft-ietf-ancp-pon-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ancp</wg_acronym>
        <doi>10.17487/RFC6934</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6935</doc-id>
        <title>IPv6 and UDP Checksums for Tunneled Packets</title>
        <author>
            <name>M. Eubanks</name>
        </author>
        <author>
            <name>P. Chimento</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Tunnel</kw>
            <kw>Encapsulation</kw>
            <kw>Integrity</kw>
            <kw>Packet Corruption</kw>
            <kw>Middlebox</kw>
        </keywords>
        <abstract><p>This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets.  The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried.  Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets.  This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum.  It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.</p></abstract>
        <draft>draft-ietf-6man-udpchecksums-08</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6935</errata-url>
        <doi>10.17487/RFC6935</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6936</doc-id>
        <title>Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>This document provides an applicability statement for the use of UDP transport checksums with IPv6.  It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum.  It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum.  The document also identifies issues and constraints for deployment on network paths that include middleboxes.  An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.</p></abstract>
        <draft>draft-ietf-6man-udpzero-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6936</errata-url>
        <doi>10.17487/RFC6936</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6937</doc-id>
        <title>Proportional Rate Reduction for TCP</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>N. Dukkipati</name>
        </author>
        <author>
            <name>Y. Cheng</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>TCP loss recovery</kw>
            <kw>packet conservation</kw>
            <kw>self clock</kw>
        </keywords>
        <abstract><p>This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms.  These algorithms determine the amount of data sent by TCP during loss recovery.  PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.</p></abstract>
        <draft>draft-ietf-tcpm-proportional-rate-reduction-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6937</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6938</doc-id>
        <title>Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID</title>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.</p></abstract>
        <draft>draft-ietf-idr-deprecate-dpa-etal-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC6938</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6939</doc-id>
        <title>Client Link-Layer Address Option in DHCPv6</title>
        <author>
            <name>G. Halwasia</name>
        </author>
        <author>
            <name>S. Bhandari</name>
        </author>
        <author>
            <name>W. Dec</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6939</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6940</doc-id>
        <title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>B. Lowekamp</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>S. Baset</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>176</page-count>
        <keywords>
            <kw>p2p</kw>
            <kw>dht</kw>
            <kw>p2psip</kw>
            <kw>chord</kw>
            <kw>peer to peer</kw>
        </keywords>
        <abstract><p>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet.  A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network.  RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application.  RELOAD defines a security model based on a certificate enrollment service that provides unique identities.  NAT traversal is a fundamental service of the protocol.  RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</p></abstract>
        <draft>draft-ietf-p2psip-base-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>p2psip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6940</errata-url>
        <doi>10.17487/RFC6940</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6941</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Security Framework</title>
        <author>
            <name>L. Fang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Niven-Jenkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Mansfield</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Graveman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>threats</kw>
            <kw>mitigation</kw>
            <kw>defensive techniques</kw>
        </keywords>
        <abstract><p>This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.</p><p> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network.</p></abstract>
        <draft>draft-ietf-mpls-tp-security-framework-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6941</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6942</doc-id>
        <title>Diameter Support for the EAP Re-authentication Protocol (ERP)</title>
        <author>
            <name>J. Bournelle</name>
        </author>
        <author>
            <name>L. Morand</name>
        </author>
        <author>
            <name>S. Decugis</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator.  This document specifies Diameter support for ERP.  It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.</p></abstract>
        <draft>draft-ietf-dime-erp-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC6942</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6943</doc-id>
        <title>Issues in Identifier Comparison for Security Purposes</title>
        <author>
            <name>D. Thaler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Canonicalization</kw>
            <kw>Normalization</kw>
            <kw>Hostname</kw>
            <kw>URI</kw>
            <kw>IRI</kw>
        </keywords>
        <abstract><p>Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources.  In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc.  If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result.  This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.</p></abstract>
        <draft>draft-iab-identifier-comparison-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6943</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6944</doc-id>
        <title>Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status</title>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>April</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data.  There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm.  This document provides an applicability statement on algorithm implementation status for DNSSEC component software.  This document lists each algorithm's status based on the current reference.  In the case that an algorithm is specified without an implementation status, this document assigns one.  This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-algo-imp-status-04</draft>
        <obsoleted-by>
            <doc-id>RFC8624</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2536</doc-id>
            <doc-id>RFC2539</doc-id>
            <doc-id>RFC3110</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4398</doc-id>
            <doc-id>RFC5155</doc-id>
            <doc-id>RFC5702</doc-id>
            <doc-id>RFC5933</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6944</errata-url>
        <doi>10.17487/RFC6944</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6945</doc-id>
        <title>Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>M. Baer</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document 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 monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.</p></abstract>
        <draft>draft-ietf-sidr-rpki-rtr-protocol-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC6945</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6946</doc-id>
        <title>Processing of IPv6 "Atomic" Fragments</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>fragmentation</kw>
            <kw>attacks</kw>
            <kw>vulnerabilities</kw>
            <kw>atomic fragments</kw>
        </keywords>
        <abstract><p>The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments").  Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet).  Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic.  This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications.  Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.</p></abstract>
        <draft>draft-ietf-6man-ipv6-atomic-fragments-04</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
            <doc-id>RFC5722</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6946</errata-url>
        <doi>10.17487/RFC6946</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6947</doc-id>
        <title>The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>H. Kaplan</name>
        </author>
        <author>
            <name>R. Gilman</name>
        </author>
        <author>
            <name>S. Veikkolainen</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.</p><p> The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.</p></abstract>
        <draft>draft-boucadair-mmusic-altc-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6947</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6948</doc-id>
        <title>Some Measurements on World IPv6 Day from an End-User Perspective</title>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services.  Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event.  The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected.  For the Internet, however, there was a major change on a short timescale.  This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity.  Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.</p></abstract>
        <draft>draft-keranen-ipv6day-measurements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6948</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6949</doc-id>
        <title>RFC Series Format Requirements and Future Development</title>
        <author>
            <name>H. Flanagan</name>
        </author>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs.  Terms are defined to help clarify exactly which stages of document production are under discussion for format changes.  The requirements described in this document will determine what changes will be made to RFC format.  This document updates RFC 2223.</p></abstract>
        <draft>draft-iab-rfcformatreq-03</draft>
        <updates>
            <doc-id>RFC2223</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6949</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6950</doc-id>
        <title>Architectural Considerations on Application Features in the DNS</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>O. Kolkman</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>A number of Internet applications rely on the Domain Name System (DNS) to support their operations.  Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS.  Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform.  This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.</p></abstract>
        <draft>draft-iab-dns-applications-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6950</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6951</doc-id>
        <title>UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.</p><p> Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.</p><p> This document covers only end-hosts and not tunneling (egress or ingress) endpoints.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-udp-encaps-14</draft>
        <updated-by>
            <doc-id>RFC8899</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC6951</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6952</doc-id>
        <title>Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide</title>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>L. Zheng</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>key</kw>
            <kw>authentication</kw>
            <kw>routing</kw>
            <kw>DoS</kw>
        </keywords>
        <abstract><p>This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.</p></abstract>
        <draft>draft-ietf-karp-routing-tcp-analysis-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>karp</wg_acronym>
        <doi>10.17487/RFC6952</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6953</doc-id>
        <title>Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements</title>
        <author>
            <name>A. Mancuso</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Probasco</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space".  The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use.  This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol.  Finally, requirements associated with the protocol are presented.</p></abstract>
        <draft>draft-ietf-paws-problem-stmt-usecases-rqmts-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>paws</wg_acronym>
        <doi>10.17487/RFC6953</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6954</doc-id>
        <title>Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>J. Merkle</name>
        </author>
        <author>
            <name>M. Lochter</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>Elliptic Curve</kw>
        </keywords>
        <abstract><p>This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).</p></abstract>
        <draft>draft-merkle-ikev2-ke-brainpool-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6954</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6955</doc-id>
        <title>Diffie-Hellman Proof-of-Possession Algorithms</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>H. Prafullchandra</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>POP</kw>
            <kw>ECDH</kw>
            <kw>DH</kw>
        </keywords>
        <abstract><p>This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.</p><p> This document obsoletes RFC 2875.</p></abstract>
        <draft>draft-schaad-pkix-rfc2875-bis-08</draft>
        <obsoletes>
            <doc-id>RFC2875</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6955</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6956</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library</title>
        <author>
            <name>W. Wang</name>
        </author>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>K. Ogawa</name>
        </author>
        <author>
            <name>C. Li</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>111</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>LFB</kw>
            <kw>Library</kw>
        </keywords>
        <abstract><p>This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES).  The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES.  The library includes the descriptions of the LFBs and the XML definitions.</p></abstract>
        <draft>draft-ietf-forces-lfb-lib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6956</errata-url>
        <doi>10.17487/RFC6956</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6957</doc-id>
        <title>Duplicate Address Detection Proxy</title>
        <author>
            <name>F. Costa</name>
        </author>
        <author>
            <name>J-M. Combes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Pougnard</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>SLAAC</kw>
            <kw>DAD</kw>
            <kw>SAVI</kw>
        </keywords>
        <abstract><p>The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures.  Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN).  When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.</p></abstract>
        <draft>draft-ietf-6man-dad-proxy-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6957</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6958</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>S. Zhang</name>
        </author>
        <author>
            <name>J. Zhao</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Real Time Control Protocol</kw>
        </keywords>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6958</errata-url>
        <doi>10.17487/RFC6958</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6959</doc-id>
        <title>Source Address Validation Improvement (SAVI) Threat Scope</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation.  This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.</p></abstract>
        <draft>draft-ietf-savi-threat-scope-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>savi</wg_acronym>
        <doi>10.17487/RFC6959</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6960</doc-id>
        <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <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>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>digital security</kw>
            <kw>ocsp</kw>
        </keywords>
        <abstract><p>This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs).  Additional mechanisms addressing PKIX operational requirements are specified in separate documents.  This document obsoletes RFCs 2560 and 6277.  It also updates RFC 5912.</p></abstract>
        <draft>draft-ietf-pkix-rfc2560bis-20</draft>
        <obsoletes>
            <doc-id>RFC2560</doc-id>
            <doc-id>RFC6277</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5912</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8954</doc-id>
            <doc-id>RFC9654</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6960</errata-url>
        <doi>10.17487/RFC6960</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6961</doc-id>
        <title>The Transport Layer Security (TLS) Multiple Certificate Status Request Extension</title>
        <author>
            <name>Y. Pettersen</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>RFC 6066</kw>
            <kw>RFC 2560</kw>
            <kw>RFC 6960</kw>
            <kw>RFC 5246</kw>
            <kw>OCSP</kw>
            <kw>OCSP stapling</kw>
            <kw>multi-stapling</kw>
            <kw>certificate status checking</kw>
            <kw>revocation information</kw>
            <kw>status_request</kw>
            <kw>status_request_v2</kw>
        </keywords>
        <abstract><p>This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.</p></abstract>
        <draft>draft-ietf-tls-multiple-cert-status-extension-08</draft>
        <obsoleted-by>
            <doc-id>RFC8446</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6961</errata-url>
        <doi>10.17487/RFC6961</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6962</doc-id>
        <title>Certificate Transparency</title>
        <author>
            <name>B. Laurie</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>E. Kasper</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>TLS certificates</kw>
        </keywords>
        <abstract><p>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</p><p> Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</p></abstract>
        <draft>draft-laurie-pki-sunlight-12</draft>
        <obsoleted-by>
            <doc-id>RFC9162</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6962</errata-url>
        <doi>10.17487/RFC6962</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6963</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for Examples</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>URN</kw>
            <kw>examples</kw>
            <kw>documentation</kw>
        </keywords>
        <abstract><p>This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.</p></abstract>
        <draft>draft-saintandre-urn-example-05</draft>
        <is-also>
            <doc-id>BCP0183</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6963</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6964</doc-id>
        <title>Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)</title>
        <author>
            <name>F. Templin</name>
        </author>
        <date>
            <month>May</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IPv4</kw>
            <kw>IPv6/IPv4</kw>
            <kw>IPv6-in-IPv4</kw>
            <kw>tunnel</kw>
            <kw>automatic</kw>
            <kw>isatap</kw>
            <kw>enterprise</kw>
            <kw>site</kw>
        </keywords>
        <abstract><p>Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures.  These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications.  As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality.  This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).</p></abstract>
        <draft>draft-templin-v6ops-isops-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6964</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6965</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design</title>
        <author>
            <name>L. Fang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>M. Daikoku</name>
        </author>
        <author>
            <name>P. Pan</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations.  The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.</p></abstract>
        <draft>draft-ietf-mpls-tp-use-cases-and-design-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6965</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6966</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6967</doc-id>
        <title>Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>P. Levis</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>Host Identifier</kw>
        </keywords>
        <abstract><p>This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.</p><p> This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.</p></abstract>
        <draft>draft-ietf-intarea-nat-reveal-analysis-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC6967</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6968</doc-id>
        <title>FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>B. Adamson</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>This document introduces the FCAST reliable object (e.g., file) delivery application.  It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.</p></abstract>
        <draft>draft-ietf-rmt-fcast-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmt</wg_acronym>
        <doi>10.17487/RFC6968</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6969</doc-id>
        <title>OSPFv3 Instance ID Registry Update</title>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>D. Cheng</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use.  It updates RFC 5838.</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-iid-registry-update-04</draft>
        <updates>
            <doc-id>RFC5838</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6969</errata-url>
        <doi>10.17487/RFC6969</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6970</doc-id>
        <title>Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>UPnP</kw>
            <kw>pinhole</kw>
            <kw>PCP</kw>
            <kw>mapping</kw>
            <kw>NAT control</kw>
            <kw>interworking</kw>
        </keywords>
        <abstract><p>This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF).  A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.</p></abstract>
        <draft>draft-ietf-pcp-upnp-igd-interworking-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC6970</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6971</doc-id>
        <title>Depth-First Forwarding (DFF) in Unreliable Networks</title>
        <author>
            <name>U. Herberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Cardenas</name>
        </author>
        <author>
            <name>T. Iwao</name>
        </author>
        <author>
            <name>M. Dow</name>
        </author>
        <author>
            <name>S. Cespedes</name>
        </author>
        <date>
            <month>June</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>DFF</kw>
            <kw>Depth first forwarding</kw>
            <kw>IPv6</kw>
            <kw>Forwarding plane</kw>
            <kw>Lossy networks</kw>
            <kw>Reliability</kw>
        </keywords>
        <abstract><p>This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links.  The protocol operates entirely on the forwarding plane but may interact with the routing plane.  DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet.  The routing plane may be informed of failures to deliver a packet or loops.  This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944.  The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not.  It is applicable for networks with little traffic and is used for unicast transmissions only.</p></abstract>
        <draft>draft-cardenas-dff-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6971</errata-url>
        <doi>10.17487/RFC6971</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6972</doc-id>
        <title>Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)</title>
        <author>
            <name>Y. Zhang</name>
        </author>
        <author>
            <name>N. Zong</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols.  This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.</p></abstract>
        <draft>draft-ietf-ppsp-problem-statement-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ppsp</wg_acronym>
        <doi>10.17487/RFC6972</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6973</doc-id>
        <title>Privacy Considerations for Internet Protocols</title>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <author>
            <name>M. Hansen</name>
        </author>
        <author>
            <name>R. Smith</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Disclosure</kw>
            <kw>Anonymity</kw>
            <kw>Pseudonymity</kw>
            <kw>Confidentiality</kw>
            <kw>Identity</kw>
        </keywords>
        <abstract><p>This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</p></abstract>
        <draft>draft-iab-privacy-considerations-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC6973</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6974</doc-id>
        <title>Applicability of MPLS Transport Profile for Ring Topologies</title>
        <author>
            <name>Y. Weingarten</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>F. Fondelli</name>
        </author>
        <author>
            <name>M. Corsi</name>
        </author>
        <author>
            <name>B. Wu</name>
        </author>
        <author>
            <name>X. Dai</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies.  This document does not propose any new mechanisms or protocols.  Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372).  This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.</p></abstract>
        <draft>draft-ietf-mpls-tp-ring-protection-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC6974</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6975</doc-id>
        <title>Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>EDNS</kw>
        </keywords>
        <abstract><p>The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be generated using different algorithms.  This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support.  The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.</p></abstract>
        <draft>draft-ietf-dnsext-dnssec-algo-signal-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnsext</wg_acronym>
        <doi>10.17487/RFC6975</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6976</doc-id>
        <title>Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach</title>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>P. Francois</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.</p><p> This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.</p><p> After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.</p><p> The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.</p></abstract>
        <draft>draft-ietf-rtgwg-ordered-fib-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC6976</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6977</doc-id>
        <title>Triggering DHCPv6 Reconfiguration from Relay Agents</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>X. Pougnard</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Reconfigure-Request</kw>
            <kw>Reconfigure-Reply</kw>
            <kw>Link Address Option</kw>
        </keywords>
        <abstract><p>This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply.  The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly.  The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.</p></abstract>
        <draft>draft-ietf-dhc-triggered-reconfigure-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC6977</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6978</doc-id>
        <title>A TCP Authentication Option Extension for NAT Traversal</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TCP-AO</kw>
        </keywords>
        <abstract><p>This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs).  This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.</p></abstract>
        <draft>draft-touch-tcp-ao-nat-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6978</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6979</doc-id>
        <title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
        <author>
            <name>T. Pornin</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>dsa</kw>
            <kw>ecdsa</kw>
            <kw>digital signature</kw>
            <kw>deterministic</kw>
        </keywords>
        <abstract><p>This document defines a deterministic digital signature generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</p></abstract>
        <draft>draft-pornin-deterministic-dsa-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc6979</errata-url>
        <doi>10.17487/RFC6979</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6980</doc-id>
        <title>Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>vulnerabilities</kw>
            <kw>evasion</kw>
            <kw>monitoring</kw>
        </keywords>
        <abstract><p>This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages.  It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks.  Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.</p></abstract>
        <draft>draft-ietf-6man-nd-extension-headers-05</draft>
        <updates>
            <doc-id>RFC3971</doc-id>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC6980</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6981</doc-id>
        <title>A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>not-via</kw>
        </keywords>
        <abstract><p>This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.</p><p> The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.</p></abstract>
        <draft>draft-ietf-rtgwg-ipfrr-notvia-addresses-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC6981</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6982</doc-id>
        <title>Improving Awareness of Running Code: The Implementation Status Section</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</p><p> The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.</p></abstract>
        <draft>draft-sheffer-running-code-06</draft>
        <obsoleted-by>
            <doc-id>RFC7942</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6982</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6983</doc-id>
        <title>Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)</title>
        <author>
            <name>R. van Brandenburg</name>
        </author>
        <author>
            <name>O. van Deventer</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>video</kw>
            <kw>caching</kw>
            <kw>HTTP</kw>
            <kw>content delivery</kw>
        </keywords>
        <abstract><p>This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios.  The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI.  This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.</p></abstract>
        <draft>draft-brandenburg-cdni-has-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6983</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6984</doc-id>
        <title>Interoperability Report for Forwarding and Control Element Separation (ForCES)</title>
        <author>
            <name>W. Wang</name>
        </author>
        <author>
            <name>K. Ogawa</name>
        </author>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>M. Gao</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China.  The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.</p></abstract>
        <draft>draft-ietf-forces-interop-09</draft>
        <updates>
            <doc-id>RFC6053</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC6984</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6985</doc-id>
        <title>IMIX Genome: Specification of Variable Packet Sizes for Additional Testing</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Traffic</kw>
            <kw>Pattern</kw>
            <kw>Benchmarking</kw>
        </keywords>
        <abstract><p>Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested.  Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX" ("Internet Mix").  The mixture of sizes a networking device will encounter is highly variable and depends on many factors.  An IMIX suited for one networking device and deployment will not be appropriate for another.  However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests.  To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.</p></abstract>
        <draft>draft-ietf-bmwg-imix-genome-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC6985</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6986</doc-id>
        <title>GOST R 34.11-2012: Hash Function</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Degtyarev</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  This document updates RFC 5831.</p></abstract>
        <draft>draft-dolmatov-gost34112012-01</draft>
        <updates>
            <doc-id>RFC5831</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC6986</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6987</doc-id>
        <title>OSPF Stub Router Advertisement</title>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ospf stub</kw>
        </keywords>
        <abstract><p>This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.</p><p> This document obsoletes RFC 3137.</p></abstract>
        <draft>draft-ietf-ospf-rfc3137bis-04</draft>
        <obsoletes>
            <doc-id>RFC3137</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8770</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6987</errata-url>
        <doi>10.17487/RFC6987</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6988</doc-id>
        <title>Requirements for Energy Management</title>
        <author>
            <name>J. Quittek</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Chandramouli</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>T. Dietz</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>monitoring functions</kw>
            <kw>control functions</kw>
        </keywords>
        <abstract><p>This document defines requirements for standards specifications for Energy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.</p><p> This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.</p></abstract>
        <draft>draft-ietf-eman-requirements-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <doi>10.17487/RFC6988</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6989</doc-id>
        <title>Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Elliptic Curve cryptography</kw>
            <kw>secret key reuse</kw>
            <kw>recipient tests</kw>
        </keywords>
        <abstract><p>This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups.  No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups.  This document updates the IKEv2 protocol, RFC 5996.</p></abstract>
        <draft>draft-ietf-ipsecme-dh-checks-05</draft>
        <updates>
            <doc-id>RFC5996</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC6989</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6990</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting</title>
        <author>
            <name>R. Huang</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RTCP</kw>
            <kw>XR</kw>
            <kw>MPEG2</kw>
            <kw>PSI</kw>
            <kw>Decodability</kw>
        </keywords>
        <abstract><p>An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data.  Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems.  This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP.  The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-decodability-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC6990</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6991</doc-id>
        <title>Common YANG Data Types</title>
        <author>
            <name>J. Schoenwaelder</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>data model</kw>
            <kw>netconf</kw>
        </keywords>
        <abstract><p>This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</p></abstract>
        <draft>draft-ietf-netmod-rfc6021-bis-03</draft>
        <obsoletes>
            <doc-id>RFC6021</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc6991</errata-url>
        <doi>10.17487/RFC6991</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6992</doc-id>
        <title>Routing for IPv4-Embedded IPv6 Packets</title>
        <author>
            <name>D. Cheng</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.</p></abstract>
        <draft>draft-ietf-ospf-ipv4-embedded-ipv6-routing-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC6992</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6993</doc-id>
        <title>Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Call-Info</kw>
            <kw>header field</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
        </keywords>
        <abstract><p>This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).</p></abstract>
        <draft>draft-saintandre-impp-call-info-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC6993</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6994</doc-id>
        <title>Shared Use of Experimental TCP Options</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier.  This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism.  It is recommended for all new TCP options that use these codepoints.</p></abstract>
        <draft>draft-ietf-tcpm-experimental-options-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC6994</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6995</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC6996</doc-id>
        <title>Autonomous System (AS) Reservation for Private Use</title>
        <author>
            <name>J. Mitchell</name>
        </author>
        <date>
            <month>July</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>asn</kw>
        </keywords>
        <abstract><p>This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use.  This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.</p></abstract>
        <draft>draft-ietf-idr-as-private-reservation-05</draft>
        <updates>
            <doc-id>RFC1930</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0006</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC6996</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6997</doc-id>
        <title>Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks</title>
        <author>
            <name>M. Goyal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Baccelli</name>
        </author>
        <author>
            <name>M. Philipp</name>
        </author>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>J. Martocci</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>P2P Routing</kw>
            <kw>RPL</kw>
            <kw>ROLL</kw>
        </keywords>
        <abstract><p>This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality.  This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.</p></abstract>
        <draft>draft-ietf-roll-p2p-rpl-17</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC6997</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC6998</doc-id>
        <title>A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network</title>
        <author>
            <name>M. Goyal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Baccelli</name>
        </author>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>J. Martocci</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Measurement</kw>
            <kw>Route Quality</kw>
            <kw>P2P Routes</kw>
            <kw>RPL</kw>
            <kw>ROLL</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.</p></abstract>
        <draft>draft-ietf-roll-p2p-measurement-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC6998</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC6999</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC7000</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC7001</doc-id>
        <title>Message Header Field for Indicating Message Authentication Status</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>DomainKeys</kw>
            <kw>SenderID</kw>
            <kw>SPF</kw>
            <kw>ADSP</kw>
            <kw>ATPS</kw>
            <kw>VBR</kw>
            <kw>Authentication</kw>
            <kw>Reputation</kw>
        </keywords>
        <abstract><p>This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.</p></abstract>
        <draft>draft-ietf-appsawg-rfc5451bis-10</draft>
        <obsoletes>
            <doc-id>RFC5451</doc-id>
            <doc-id>RFC6577</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7601</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC7410</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7001</errata-url>
        <doi>10.17487/RFC7001</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7002</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-discard-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7002</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7003</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Real Time Control Protocol</kw>
        </keywords>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7003</errata-url>
        <doi>10.17487/RFC7003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7004</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>R. Schott</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RTCP XR</kw>
            <kw>Summary Statistics</kw>
            <kw>Burst/Gap Loss</kw>
            <kw>Burst/Gap Discard</kw>
            <kw>Frame Impairment</kw>
        </keywords>
        <abstract><p>This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-summary-stat-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7004</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7005</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-jb-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7006</doc-id>
        <title>Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>S. Veikkolainen</name>
        </author>
        <author>
            <name>R. Gilman</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>title capability</kw>
            <kw>connection data capability</kw>
            <kw>bandwidth capability</kw>
        </keywords>
        <abstract><p>The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.</p><p> This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).</p></abstract>
        <draft>draft-ietf-mmusic-sdp-miscellaneous-caps-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7006</errata-url>
        <doi>10.17487/RFC7006</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7007</doc-id>
        <title>Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)</title>
        <author>
            <name>T. Terriberry</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF).  This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.</p></abstract>
        <draft>draft-ietf-avtcore-avp-codecs-03</draft>
        <updates>
            <doc-id>RFC3551</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7007</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7008</doc-id>
        <title>A Description of the KCipher-2 Encryption Algorithm</title>
        <author>
            <name>S. Kiyomoto</name>
        </author>
        <author>
            <name>W. Shin</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>stream cipher</kw>
            <kw>cipher</kw>
        </keywords>
        <abstract><p>This document describes the KCipher-2 encryption algorithm.  KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector.  Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies.  As of the publication of this document, no security vulnerabilities have been found.  KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation.  KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.</p></abstract>
        <draft>draft-kiyomoto-kcipher2-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7008</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7009</doc-id>
        <title>OAuth 2.0 Token Revocation</title>
        <author>
            <name>T. Lodderstedt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Dronia</name>
        </author>
        <author>
            <name>M. Scurtescu</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed.  This allows the authorization server to clean up security credentials.  A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.</p></abstract>
        <draft>draft-ietf-oauth-revocation-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7009</errata-url>
        <doi>10.17487/RFC7009</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7010</doc-id>
        <title>IPv6 Site Renumbering Gap Analysis</title>
        <author>
            <name>B. Liu</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>W. George</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.  The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate.  The gap analysis is organized by the main steps of a renumbering process.</p></abstract>
        <draft>draft-ietf-6renum-gap-analysis-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>6renum</wg_acronym>
        <doi>10.17487/RFC7010</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7011</doc-id>
        <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
        <author>
            <name>B. Claise</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Trammell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <abstract><p>This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.</p></abstract>
        <draft>draft-ietf-ipfix-protocol-rfc5101bis-10</draft>
        <obsoletes>
            <doc-id>RFC5101</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0077</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7011</errata-url>
        <doi>10.17487/RFC7011</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7012</doc-id>
        <title>Information Model for IP Flow Information Export (IPFIX)</title>
        <author>
            <name>B. Claise</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Trammell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol.  This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102.  This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications.  This document obsoletes RFC 5102.</p></abstract>
        <draft>draft-ietf-ipfix-information-model-rfc5102bis-10</draft>
        <obsoletes>
            <doc-id>RFC5102</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7012</errata-url>
        <doi>10.17487/RFC7012</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7013</doc-id>
        <title>Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>IE-DOCTORS</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol.  It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.</p></abstract>
        <draft>draft-ietf-ipfix-ie-doctors-07</draft>
        <is-also>
            <doc-id>BCP0184</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC7013</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7014</doc-id>
        <title>Flow Selection Techniques</title>
        <author>
            <name>S. D'Antonio</name>
        </author>
        <author>
            <name>T. Zseby</name>
        </author>
        <author>
            <name>C. Henke</name>
        </author>
        <author>
            <name>L. Peluso</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows.  The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator.  It reduces the effort of post-processing Flow data and transferring Flow Records.  This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques.  It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.</p></abstract>
        <draft>draft-ietf-ipfix-flow-selection-tech-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC7014</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7015</doc-id>
        <title>Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>A. Wagner</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>Flow metering</kw>
            <kw>Flow measurement</kw>
            <kw>IPFIX mediator</kw>
        </keywords>
        <abstract><p>This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties.  It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.</p></abstract>
        <draft>draft-ietf-ipfix-a9n-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC7015</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7016</doc-id>
        <title>Adobe's Secure Real-Time Media Flow Protocol</title>
        <author>
            <name>M. Thornburgh</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>113</page-count>
        <keywords>
            <kw>RTMFP</kw>
        </keywords>
        <abstract><p>This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks.  RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.</p></abstract>
        <draft>draft-thornburgh-adobe-rtmfp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7016</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7017</doc-id>
        <title>IMAP Access to IETF Email List Archives</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>The IETF makes heavy use of email lists to conduct its work.  This often involves accessing the archived history of those email lists.  Participants would like to have the ability to browse and search those archives using standard IMAP clients.  This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.</p></abstract>
        <draft>draft-sparks-genarea-imaparch-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7017</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7018</doc-id>
        <title>Auto-Discovery VPN Problem Statement and Requirements</title>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>S. Hanna</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>Overlay</kw>
            <kw>SDN</kw>
            <kw>IKE</kw>
        </keywords>
        <abstract><p>This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.</p><p> Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.</p></abstract>
        <draft>draft-ietf-ipsecme-ad-vpn-problem-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC7018</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7019</doc-id>
        <title>Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)</title>
        <author>
            <name>J. Buford</name>
        </author>
        <author>
            <name>M. Kolberg</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>application-layer multicast</kw>
        </keywords>
        <abstract><p>We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast.</p><p> This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).</p></abstract>
        <draft>draft-irtf-samrg-sam-baseline-protocol-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7019</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7020</doc-id>
        <title>The Internet Numbers Registry System</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>J. Curran</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>D. Conrad</name>
        </author>
        <date>
            <month>August</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.</p><p> This document also provides information about the processes for further evolution of the Internet Numbers Registry System.</p><p> This document replaces RFC 2050.</p><p> This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.</p></abstract>
        <draft>draft-housley-rfc2050bis-02</draft>
        <obsoletes>
            <doc-id>RFC2050</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7020</errata-url>
        <doi>10.17487/RFC7020</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7021</doc-id>
        <title>Assessing the Impact of Carrier-Grade NAT on Network Applications</title>
        <author>
            <name>C. Donley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Howard</name>
        </author>
        <author>
            <name>V. Kuarsingh</name>
        </author>
        <author>
            <name>J. Berg</name>
        </author>
        <author>
            <name>J. Doshi</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>CGN</kw>
            <kw>NAT444</kw>
            <kw>DS-Lite</kw>
            <kw>Dual-Stack Lite</kw>
            <kw>IPv4</kw>
            <kw>NAT</kw>
            <kw>IPv6</kw>
            <kw>LSN transition</kw>
        </keywords>
        <abstract><p>NAT444 is an IPv4 extension technology being considered by Service Providers as a means to continue offering IPv4 service to customers while transitioning to IPv6.  This technology adds an extra Carrier- Grade NAT (CGN) in the Service Provider network, often resulting in two NATs.  CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment.  This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications.  This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.</p></abstract>
        <draft>draft-donley-nat444-impacts-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7021</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7022</doc-id>
        <title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.</p><p> For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222.</p></abstract>
        <draft>draft-ietf-avtcore-6222bis-06</draft>
        <obsoletes>
            <doc-id>RFC6222</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3550</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7022</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7023</doc-id>
        <title>MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking</title>
        <author>
            <name>D. Mohan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Bitar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. DeLord</name>
        </author>
        <author>
            <name>P. Niger</name>
        </author>
        <author>
            <name>R. Qiu</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (PWE3) architecture to realize an end-to-end emulated Ethernet service.  It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.</p></abstract>
        <draft>draft-ietf-pwe3-mpls-eth-oam-iwk-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7024</doc-id>
        <title>Virtual Hub-and-Spoke in BGP/MPLS VPNs</title>
        <author>
            <name>H. Jeng</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.</p><p> Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.</p></abstract>
        <draft>draft-ietf-l3vpn-virtual-hub-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC7024</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7025</doc-id>
        <title>Requirements for GMPLS Applications of PCE</title>
        <author>
            <name>T. Otani</name>
        </author>
        <author>
            <name>K. Ogaki</name>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>C. Margaria</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Path Computation</kw>
            <kw>CSPF</kw>
            <kw>PCC</kw>
            <kw>Traffic Engineering</kw>
            <kw>TE</kw>
        </keywords>
        <abstract><p>The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS.  As a next step, this document describes functional requirements for GMPLS applications of PCE.</p></abstract>
        <draft>draft-ietf-pce-gmpls-aps-req-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7025</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7026</doc-id>
        <title>Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>ACH</kw>
            <kw>G-ACh</kw>
            <kw>Pseudowire</kw>
            <kw>PW</kw>
            <kw>MPLS-TP</kw>
        </keywords>
        <abstract><p>The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs</p><p> No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.</p><p> This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.</p></abstract>
        <draft>draft-ietf-mpls-retire-ach-tlv-03</draft>
        <updates>
            <doc-id>RFC5586</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7026</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7027</doc-id>
        <title>Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)</title>
        <author>
            <name>J. Merkle</name>
        </author>
        <author>
            <name>M. Lochter</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>Elliptic Curve Cryptography</kw>
        </keywords>
        <abstract><p>This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.</p></abstract>
        <draft>draft-merkle-tls-brainpool-04</draft>
        <updates>
            <doc-id>RFC4492</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7027</errata-url>
        <doi>10.17487/RFC7027</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7028</doc-id>
        <title>Multicast Mobility Routing Optimizations for Proxy Mobile IPv6</title>
        <author>
            <name>JC. Zuniga</name>
        </author>
        <author>
            <name>LM. Contreras</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>S. Jeon</name>
        </author>
        <author>
            <name>Y. Kim</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>multimob</kw>
            <kw>PMIPv6</kw>
            <kw>MTMA</kw>
            <kw>selector</kw>
            <kw>MLD</kw>
            <kw>IGMP</kw>
        </keywords>
        <abstract><p>This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain.  These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network.  The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.</p></abstract>
        <draft>draft-ietf-multimob-pmipv6-ropt-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>multimob</wg_acronym>
        <doi>10.17487/RFC7028</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7029</doc-id>
        <title>Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>M. Wasserman</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MITM</kw>
            <kw>man-in-the-middle</kw>
            <kw>EMSK crypto binding</kw>
            <kw>Extended Master Session Key</kw>
            <kw>tunnel</kw>
        </keywords>
        <abstract><p>As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server.  EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information.  Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks.  However, cryptographic binding focuses on protecting the server rather than the peer.  This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.</p></abstract>
        <draft>draft-ietf-emu-crypto-bind-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC7029</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7030</doc-id>
        <title>Enrollment over Secure Transport</title>
        <author>
            <name>M. Pritikin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Yee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Harkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>pki</kw>
            <kw>est</kw>
        </keywords>
        <abstract><p>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</p></abstract>
        <draft>draft-ietf-pkix-est-09</draft>
        <updated-by>
            <doc-id>RFC8951</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pkix</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7030</errata-url>
        <doi>10.17487/RFC7030</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7031</doc-id>
        <title>DHCPv6 Failover Requirements</title>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Failover</kw>
        </keywords>
        <abstract><p>The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases.  Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure.  In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information.  RFC 3315 allows for, but does not define, any redundancy or failover mechanisms.  This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted.  This document does not define a DHCPv6 failover protocol.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-failover-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7031</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7032</doc-id>
        <title>LDP Downstream-on-Demand in Seamless MPLS</title>
        <author>
            <name>T. Beckhaus</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>K. Tiruveedhula</name>
        </author>
        <author>
            <name>M. Konstantynowicz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.</p><p> In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.</p></abstract>
        <draft>draft-ietf-mpls-ldp-dod-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7032</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7033</doc-id>
        <title>WebFinger</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Smarr</name>
        </author>
        <date>
            <month>September</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>WebFinger</kw>
            <kw>JRD</kw>
            <kw> JSON Resource Descriptor</kw>
            <kw>service discovery</kw>
            <kw>service discovery protocol</kw>
            <kw>information discovery</kw>
            <kw>information discovery protocol</kw>
        </keywords>
        <abstract><p>This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods.  WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</p></abstract>
        <draft>draft-ietf-appsawg-webfinger-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7033</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7034</doc-id>
        <title>HTTP Header Field X-Frame-Options</title>
        <author>
            <name>D. Ross</name>
        </author>
        <author>
            <name>T. Gondrom</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>frame-options</kw>
            <kw>HTTP header</kw>
            <kw>websec</kw>
        </keywords>
        <abstract><p>To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.</p></abstract>
        <draft>draft-ietf-websec-x-frame-options-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>websec</wg_acronym>
        <doi>10.17487/RFC7034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7035</doc-id>
        <title>Relative Location Representation</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>D. Stanley</name>
        </author>
        <author>
            <name>G. Bajko</name>
        </author>
        <author>
            <name>A. Thomson</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>Relative</kw>
            <kw>location</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.</p><p> Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.</p></abstract>
        <draft>draft-ietf-geopriv-relative-location-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC7035</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7036</doc-id>
        <title>Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group.  This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.</p></abstract>
        <draft>draft-housley-ltans-oids-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7036</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7037</doc-id>
        <title>RADIUS Option for the DHCPv6 Relay Agent</title>
        <author>
            <name>L. Yeh</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>RADIUS</kw>
        </keywords>
        <abstract><p>The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server.  This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client.  When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server.  The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-radius-opt-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7037</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7038</doc-id>
        <title>Use of OSPF-MDR in Single-Hop Broadcast Networks</title>
        <author>
            <name>R. Ogier</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>mobile ad hoc network</kw>
            <kw>MANET designated router</kw>
            <kw>wireless</kw>
            <kw>point-to-multipoint interface</kw>
        </keywords>
        <abstract><p>RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET.  This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router.  Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor.  The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.</p></abstract>
        <draft>draft-ietf-ospf-manet-single-hop-mdr-04</draft>
        <updates>
            <doc-id>RFC5614</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7038</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7039</doc-id>
        <title>Source Address Validation Improvement (SAVI) Framework</title>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>J. Bi</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>C. Vogt</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>anti-spoofing</kw>
            <kw>BCP38</kw>
            <kw>ingress filtering</kw>
        </keywords>
        <abstract><p>Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation.  This document is a framework document that describes and motivates the design of the SAVI methods.  Particular SAVI methods are described in other documents.</p></abstract>
        <draft>draft-ietf-savi-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>savi</wg_acronym>
        <doi>10.17487/RFC7039</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7040</doc-id>
        <title>Public IPv4-over-IPv6 Access Network</title>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>P. Wu</name>
        </author>
        <author>
            <name>O. Vautrin</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Public 4over6</kw>
            <kw>IPv4 over IPv6</kw>
            <kw>Access Network</kw>
            <kw>DHCPv4 over IPv6</kw>
            <kw>IPv6 Tunnel</kw>
            <kw>IPv6 Transition</kw>
        </keywords>
        <abstract><p>This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses.  Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments.  Future deployments of similar scenarios should use Lightweight 4over6.  Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network.  The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay.  Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.</p></abstract>
        <draft>draft-ietf-softwire-public-4over6-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC7040</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7041</doc-id>
        <title>Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging</title>
        <author>
            <name>F. Balus</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Bitar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported.</p><p> The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.</p><p> This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.</p></abstract>
        <draft>draft-ietf-l2vpn-pbb-vpls-pe-model-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC7041</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7042</doc-id>
        <title>IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>J. Abley</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Ethernet</kw>
            <kw>Ethertype</kw>
            <kw>802</kw>
            <kw>OUI</kw>
            <kw>EUI</kw>
            <kw>LSAP</kw>
        </keywords>
        <abstract><p>Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters.  This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation.  This document obsoletes RFC 5342.</p></abstract>
        <draft>draft-eastlake-rfc5342bis-05</draft>
        <obsoletes>
            <doc-id>RFC5342</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9542</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2153</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7043</doc-id>
        <title>Resource Records for EUI-48 and EUI-64 Addresses in the DNS</title>
        <author>
            <name>J. Abley</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IEEE</kw>
            <kw>ethernet</kw>
        </keywords>
        <abstract><p>48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.</p><p> This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS.</p><p> This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.</p></abstract>
        <draft>draft-jabley-dnsext-eui48-eui64-rrtypes-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7043</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7044</doc-id>
        <title>An Extension to the Session Initiation Protocol (SIP) for Request History Information</title>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <author>
            <name>S. Schubert</name>
        </author>
        <author>
            <name>J. van Elburg</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>history-info</kw>
            <kw>retarget</kw>
            <kw>enhanced services</kw>
            <kw>voicemail</kw>
            <kw>automatic call distribution</kw>
        </keywords>
        <abstract><p>This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request.  This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user.  This document defines an optional SIP header field, History-Info, for capturing the history information in requests.  The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined.  In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field.  This document obsoletes RFC 4244.</p></abstract>
        <draft>draft-ietf-sipcore-rfc4244bis-12</draft>
        <obsoletes>
            <doc-id>RFC4244</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7044</errata-url>
        <doi>10.17487/RFC7044</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7045</doc-id>
        <title>Transmission and Processing of IPv6 Extension Headers</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Various IPv6 extension headers have been standardised since the IPv6 standard was first published.  This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future.  It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.</p></abstract>
        <draft>draft-ietf-6man-ext-transmit-05</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
            <doc-id>RFC2780</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7045</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7046</doc-id>
        <title>A Common API for Transparent Hybrid Multicast</title>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <author>
            <name>T. Schmidt</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Peer-to-Peer (P2P)</kw>
            <kw>adaptive multicast</kw>
            <kw>multicast  naming</kw>
            <kw>multicast addressing</kw>
        </keywords>
        <abstract><p>Group communication services exist in a large variety of flavors and technical implementations at different protocol layers.  Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime.  Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network.  Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself.  This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast.  It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies.  Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet.  It reports on an implementation of the programming Interface, including service middleware.  This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.</p></abstract>
        <draft>draft-irtf-samrg-common-api-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7046</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7047</doc-id>
        <title>The Open vSwitch Database Management Protocol</title>
        <author>
            <name>B. Pfaff</name>
        </author>
        <author>
            <name>B. Davie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>vswitch</kw>
            <kw>virtualization</kw>
            <kw>overlay</kw>
            <kw>OVS</kw>
        </keywords>
        <abstract><p>Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments.  A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network.  Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol.  This document defines the OVSDB management protocol.  The Open vSwitch project includes open-source OVSDB client and server implementations.</p></abstract>
        <draft>draft-pfaff-ovsdb-proto-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7047</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7048</doc-id>
        <title>Neighbor Unreachability Detection Is Too Impatient</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>I. Gashinsky</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>6MAN</kw>
            <kw>IPv6</kw>
            <kw>Neighbor Discovery</kw>
        </keywords>
        <abstract><p>IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.  That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time.  By default, this time is 3 seconds after the node starts probing.  However, if there are no alternative neighbors, this timeout behavior is far too impatient.  This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors.  This document updates RFC 4861.</p></abstract>
        <draft>draft-ietf-6man-impatient-nud-07</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7048</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7049</doc-id>
        <title>Concise Binary Object Representation (CBOR)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>parser</kw>
            <kw>encoder</kw>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.  These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</p></abstract>
        <draft>draft-bormann-cbor-09</draft>
        <obsoleted-by>
            <doc-id>RFC8949</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7049</errata-url>
        <doi>10.17487/RFC7049</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7050</doc-id>
        <title>Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis</title>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>NAT64</kw>
            <kw>DNS64</kw>
            <kw>464XLAT</kw>
            <kw>Pref64::/n</kw>
        </keywords>
        <abstract><p>This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network.  The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.".  The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.</p></abstract>
        <draft>draft-ietf-behave-nat64-discovery-heuristic-17</draft>
        <updated-by>
            <doc-id>RFC8880</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7050</errata-url>
        <doi>10.17487/RFC7050</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7051</doc-id>
        <title>Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Savolainen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>NAT64</kw>
            <kw>DNS64</kw>
            <kw>464XLAT</kw>
            <kw>Pref64::/n</kw>
        </keywords>
        <abstract><p>Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network.  This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64.  These solutions enable both NAT64 avoidance and local IPv6 address synthesis.  The document concludes by recommending the standardization of the approach based on heuristic discovery.</p></abstract>
        <draft>draft-ietf-behave-nat64-learn-analysis-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>behave</wg_acronym>
        <doi>10.17487/RFC7051</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7052</doc-id>
        <title>Locator/ID Separation Protocol (LISP) MIB</title>
        <author>
            <name>G. Schudel</name>
        </author>
        <author>
            <name>A. Jain</name>
        </author>
        <author>
            <name>V. Moreno</name>
        </author>
        <date>
            <month>October</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <abstract><p>This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP).  These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.</p></abstract>
        <draft>draft-ietf-lisp-mib-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7052</errata-url>
        <doi>10.17487/RFC7052</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7053</doc-id>
        <title>SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>I. Ruengeler</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed.  It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack.  Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-sack-immediately-04</draft>
        <obsoleted-by>
            <doc-id>RFC9260</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4960</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC7053</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7054</doc-id>
        <title>Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>H. Endo</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>Y. Koike</name>
        </author>
        <author>
            <name>M. Paul</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.</p><p> This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.</p></abstract>
        <draft>draft-ietf-mpls-tp-mip-mep-map-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7054</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7055</doc-id>
        <title>A GSS-API Mechanism for the Extensible Authentication Protocol</title>
        <author>
            <name>S. Hartman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Howlett</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism.  Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.</p></abstract>
        <draft>draft-ietf-abfab-gss-eap-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>abfab</wg_acronym>
        <doi>10.17487/RFC7055</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7056</doc-id>
        <title>Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>J. Howlett</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names.  The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response.  It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response.  This document describes how to use the Naming Extensions API to access that information.</p></abstract>
        <draft>draft-ietf-abfab-gss-eap-naming-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>abfab</wg_acronym>
        <doi>10.17487/RFC7056</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7057</doc-id>
        <title>Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)</title>
        <author>
            <name>S. Winter</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>AAA</kw>
        </keywords>
        <abstract><p>This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.</p></abstract>
        <draft>draft-ietf-abfab-eapapplicability-06</draft>
        <updates>
            <doc-id>RFC3748</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>abfab</wg_acronym>
        <doi>10.17487/RFC7057</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7058</doc-id>
        <title>Media Control Channel Framework (CFW) Call Flow Examples</title>
        <author>
            <name>A. Amirante</name>
        </author>
        <author>
            <name>T. Castaldi</name>
        </author>
        <author>
            <name>L. Miniero</name>
        </author>
        <author>
            <name>S P. Romano</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>182</page-count>
        <keywords>
            <kw>MediaCtrl</kw>
            <kw>Media Server Control</kw>
            <kw>Media Control Channel Framework</kw>
        </keywords>
        <abstract><p>This document provides a list of typical Media Control Channel Framework call flows.  It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.</p></abstract>
        <draft>draft-ietf-mediactrl-call-flows-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mediactrl</wg_acronym>
        <doi>10.17487/RFC7058</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7059</doc-id>
        <title>A Comparison of IPv6-over-IPv4 Tunnel Mechanisms</title>
        <author>
            <name>S. Steffann</name>
        </author>
        <author>
            <name>I. van Beijnum</name>
        </author>
        <author>
            <name>R. van Rein</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks.  It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication.  The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.</p></abstract>
        <draft>draft-steffann-tunnels-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7059</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7060</doc-id>
        <title>Using LDP Multipoint Extensions on Targeted LDP Sessions</title>
        <author>
            <name>M. Napierala</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths.  However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected.  The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session.  This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.</p></abstract>
        <draft>draft-ietf-mpls-targeted-mldp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7060</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7061</doc-id>
        <title>eXtensible Access Control Markup Language (XACML) XML Media Type</title>
        <author>
            <name>R. Sinnema</name>
        </author>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).</p></abstract>
        <draft>draft-sinnema-xacml-media-type-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7061</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7062</doc-id>
        <title>Framework for GMPLS and PCE Control of G.709 Optical Transport Networks</title>
        <author>
            <name>F. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>S. Belotti</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-g709-framework-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7062</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7063</doc-id>
        <title>Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments</title>
        <author>
            <name>L. Zheng</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>R. Parekh</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.</p></abstract>
        <draft>draft-ietf-pim-rfc4601-update-survey-report-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC7063</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7064</doc-id>
        <title>URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol</title>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.</p></abstract>
        <draft>draft-nandakumar-rtcweb-stun-uri-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7064</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7065</doc-id>
        <title>Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol.  It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).</p></abstract>
        <draft>draft-petithuguenin-behave-turn-uris-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7065</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7066</doc-id>
        <title>IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Arkko</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet.  Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications.  However, the concept of IPv6 covers many aspects and numerous specifications.  In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used.  This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks).  This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434).  It also discusses some issues related to the use of these components when operating in these networks.  This document obsoletes RFC 3316.</p></abstract>
        <draft>draft-ietf-v6ops-rfc3316bis-06</draft>
        <obsoletes>
            <doc-id>RFC3316</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7066</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7067</doc-id>
        <title>Directory Assistance Problem and High-Level Design Proposal</title>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>I. Gashinsky</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>Orchestration</kw>
            <kw>Directory</kw>
            <kw>Push</kw>
            <kw>Pull</kw>
            <kw>RBridge</kw>
            <kw>ARP</kw>
        </keywords>
        <abstract><p>Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&amp;Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus.</p><p> This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.</p></abstract>
        <draft>draft-ietf-trill-directory-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7067</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7068</doc-id>
        <title>Diameter Overload Control Requirements</title>
        <author>
            <name>E. McMurry</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time.  Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition.  The existing Diameter mechanisms are not sufficient for managing overload conditions.  This document describes the limitations of the existing mechanisms.  Requirements for new overload management mechanisms are also provided.</p></abstract>
        <draft>draft-ietf-dime-overload-reqs-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7068</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7069</doc-id>
        <title>DECoupled Application Data Enroute (DECADE)</title>
        <author>
            <name>R. Alimi</name>
        </author>
        <author>
            <name>A. Rahman</name>
        </author>
        <author>
            <name>D. Kutscher</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>K. Pentikousis</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>decade</kw>
        </keywords>
        <abstract><p>Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks.  Often, however, content distribution applications use network resources inefficiently.  One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms.  This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document.  DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources.  This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.</p></abstract>
        <draft>draft-alimi-decade-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7069</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7070</doc-id>
        <title>An Architecture for Reputation Reporting</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>security</kw>
            <kw>messaging</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>authentication</kw>
            <kw>reputation</kw>
        </keywords>
        <abstract><p>This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name.  The document roughly follows the recommendations of RFC 4101 for describing a protocol model.</p></abstract>
        <draft>draft-ietf-repute-model-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>repute</wg_acronym>
        <doi>10.17487/RFC7070</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7071</doc-id>
        <title>A Media Type for Reputation Interchange</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>reputation</kw>
            <kw>domain</kw>
            <kw>security</kw>
            <kw>messaging</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.</p></abstract>
        <draft>draft-ietf-repute-media-type-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>repute</wg_acronym>
        <doi>10.17487/RFC7071</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7072</doc-id>
        <title>A Reputation Query Protocol</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>reputation</kw>
            <kw>domain</kw>
            <kw>security</kw>
            <kw>messaging</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.</p></abstract>
        <draft>draft-ietf-repute-query-http-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>repute</wg_acronym>
        <doi>10.17487/RFC7072</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7073</doc-id>
        <title>A Reputation Response Set for Email Identifiers</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>reputation</kw>
            <kw>domain</kw>
            <kw>security</kw>
            <kw>messaging</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.</p></abstract>
        <draft>draft-ietf-repute-email-identifiers-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>repute</wg_acronym>
        <doi>10.17487/RFC7073</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7074</doc-id>
        <title>Revised Definition of the GMPLS Switching Capability and Type Fields</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>J. Meuric</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology.  GMPLS routing and signaling use common values to indicate the type of switching technology.  These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field.  While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS.  This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields.  This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.</p></abstract>
        <draft>draft-ietf-ccamp-swcaps-update-03</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
            <doc-id>RFC4202</doc-id>
            <doc-id>RFC4203</doc-id>
            <doc-id>RFC5307</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7075</doc-id>
        <title>Realm-Based Redirection In Diameter</title>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>R. Hao</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".</p><p> This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).</p></abstract>
        <draft>draft-ietf-dime-realm-based-redirect-13</draft>
        <updates>
            <doc-id>RFC6733</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7075</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7076</doc-id>
        <title>P6R's Secure Shell Public Key Subsystem</title>
        <author>
            <name>M. Joseph</name>
        </author>
        <author>
            <name>J. Susoy</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>key management</kw>
            <kw>certificate management</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.</p><p> The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).</p><p> The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).</p><p> Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.</p></abstract>
        <draft>draft-joseph-pkix-p6rsshextension-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7077</doc-id>
        <title>Update Notifications for Proxy Mobile IPv6</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>M. Liebsch</name>
        </author>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MIPv6</kw>
        </keywords>
        <abstract><p>This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session.  These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.</p></abstract>
        <draft>draft-ietf-netext-update-notifications-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7077</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7078</doc-id>
        <title>Distributing Address Selection Policy Using DHCPv6</title>
        <author>
            <name>A. Matsumoto</name>
        </author>
        <author>
            <name>T. Fujisaki</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between.  RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information.  This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.</p></abstract>
        <draft>draft-ietf-6man-addr-select-opt-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7079</doc-id>
        <title>The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results</title>
        <author>
            <name>N. Del Regno</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Control Word (CW)</kw>
            <kw>Control Channel (CC)</kw>
        </keywords>
        <abstract><p>The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data.  In most of these encapsulations, use of the Pseudowire (PW) Control Word is required.  However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations.  This survey of the Pseudowire / Virtual Circuit Connectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.</p></abstract>
        <draft>draft-ietf-pwe3-vccv-impl-survey-results-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7079</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7080</doc-id>
        <title>Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges</title>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>F. Balus</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>h-vpls</kw>
        </keywords>
        <abstract><p>The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access.  Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008.  It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks.  This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances.  The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them.  Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.</p></abstract>
        <draft>draft-ietf-l2vpn-pbb-vpls-interop-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC7080</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7081</doc-id>
        <title>CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>E. Ivov</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>E. Marocco</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>real-time communication</kw>
            <kw>unified communication</kw>
            <kw>voice</kw>
            <kw>video</kw>
            <kw>instant messaging</kw>
            <kw>chat</kw>
            <kw>presence</kw>
            <kw>telephony</kw>
        </keywords>
        <abstract><p>This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers.  Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP.  Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP.  This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices".  Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.</p></abstract>
        <draft>draft-ivov-xmpp-cusax-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7082</doc-id>
        <title>Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)</title>
        <author>
            <name>R. Shekh-Yusef</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.</p><p> This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the &lt;service-uris&gt; element in the SIP conferencing event package.</p></abstract>
        <draft>draft-yusef-dispatch-ccmp-indication-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7082</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7083</doc-id>
        <title>Modification to Default Values of SOL_MAX_RT and INF_MAX_RT</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with new values.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-solmaxrt-update-05</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3315</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7083</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7084</doc-id>
        <title>Basic Requirements for IPv6 Customer Edge Routers</title>
        <author>
            <name>H. Singh</name>
        </author>
        <author>
            <name>W. Beebee</name>
        </author>
        <author>
            <name>C. Donley</name>
        </author>
        <author>
            <name>B. Stark</name>
        </author>
        <date>
            <month>November</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>6rd</kw>
            <kw>DS-Lite</kw>
        </keywords>
        <abstract><p>This document specifies requirements for an IPv6 Customer Edge (CE) router.  Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.  The document also covers IP transition technologies.  Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document.  The document obsoletes RFC 6204.</p></abstract>
        <draft>draft-ietf-v6ops-6204bis-12</draft>
        <obsoletes>
            <doc-id>RFC6204</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9096</doc-id>
            <doc-id>RFC9818</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7084</errata-url>
        <doi>10.17487/RFC7084</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7085</doc-id>
        <title>Top-Level Domains That Are Already Dotless</title>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>Recent statements from the Internet Architecture Board (IAB) and the Internet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains").  In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them.  This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.</p></abstract>
        <draft>draft-hoffine-already-dotless-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7085</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7086</doc-id>
        <title>Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)</title>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Maenpaa</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>overlay</kw>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol.  The document provides the details needed to build a RELOAD-based overlay that uses HIP.</p></abstract>
        <draft>draft-ietf-hip-reload-instance-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC7086</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7087</doc-id>
        <title>A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations</title>
        <author>
            <name>H. van Helvoort</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Andersson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Sprecher</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture.</p><p> This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations.</p><p> It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.</p></abstract>
        <draft>draft-ietf-mpls-tp-rosetta-stone-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7087</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7088</doc-id>
        <title>Session Initiation Protocol Service Example -- Music on Hold</title>
        <author>
            <name>D. Worley</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Music on hold</kw>
        </keywords>
        <abstract><p>"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems.  Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party.  Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant.  The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented.  In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.</p></abstract>
        <draft>draft-worley-service-example-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7089</doc-id>
        <title>HTTP Framework for Time-Based Access to Resource States -- Memento</title>
        <author>
            <name>H. Van de Sompel</name>
        </author>
        <author>
            <name>M. Nelson</name>
        </author>
        <author>
            <name>R. Sanderson</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>content negotiation</kw>
            <kw>datetime negotiation</kw>
            <kw>resource versions</kw>
            <kw>archival resources</kw>
            <kw>Memento</kw>
        </keywords>
        <abstract><p>The HTTP-based Memento framework bridges the present and past Web.  It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps.  Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime.  TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource.  The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.</p></abstract>
        <draft>draft-vandesompel-memento-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7089</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7090</doc-id>
        <title>Public Safety Answering Point (PSAP) Callback</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>M. Patel</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>PSAP</kw>
            <kw>callback</kw>
            <kw>SIP</kw>
            <kw>emergency</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract><p>After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.</p><p> The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.</p></abstract>
        <draft>draft-ietf-ecrit-psap-callback-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC7090</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7091</doc-id>
        <title>GOST R 34.10-2012: Digital Signature Algorithm</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Degtyarev</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms).  Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification.  This document updates RFC 5832.</p></abstract>
        <draft>draft-dolmatov-gost34102012-00</draft>
        <updates>
            <doc-id>RFC5832</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7091</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7092</doc-id>
        <title>A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents</title>
        <author>
            <name>H. Kaplan</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>B2BUA</kw>
            <kw>taxonomy</kw>
        </keywords>
        <abstract><p>In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).</p><p> There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.</p></abstract>
        <draft>draft-ietf-straw-b2bua-taxonomy-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>straw</wg_acronym>
        <doi>10.17487/RFC7092</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7093</doc-id>
        <title>Additional Methods for Generating Key Identifiers Values</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>J. Manger</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.</p></abstract>
        <draft>draft-turner-additional-methods-4kis-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7094</doc-id>
        <title>Architectural Considerations of IP Anycast</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>E. Osterweil</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>anycast</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract><p>This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.</p></abstract>
        <draft>draft-iab-anycast-arch-implications-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7095</doc-id>
        <title>jCard: The JSON Format for vCard</title>
        <author>
            <name>P. Kewisch</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>jCard</kw>
            <kw>JSON</kw>
            <kw>vCard</kw>
            <kw>addressbook</kw>
            <kw>contacts</kw>
            <kw>CardDAV</kw>
            <kw>PIM</kw>
        </keywords>
        <abstract><p>This specification defines "jCard", a JSON format for vCard data.  The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</p></abstract>
        <draft>draft-ietf-jcardcal-jcard-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>jcardcal</wg_acronym>
        <doi>10.17487/RFC7095</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7096</doc-id>
        <title>Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)</title>
        <author>
            <name>S. Belotti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Grandi</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Caviglia</name>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>CCAMP Working Group</kw>
            <kw>OSPF</kw>
            <kw>GMPLS</kw>
            <kw>G709</kw>
            <kw>OTN</kw>
        </keywords>
        <abstract><p>ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).</p><p> This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.</p></abstract>
        <draft>draft-ietf-ccamp-otn-g709-info-model-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7096</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7097</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>V. Singh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Curcio</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>RTCP</kw>
            <kw>discard metrics</kw>
        </keywords>
        <abstract><p>The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics.  The available reporting may include aggregate information across longer periods of time as well as individual packet reporting.  This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7097</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7098</doc-id>
        <title>Using the IPv6 Flow Label for Load Balancing in Server Farms</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>W. Tarreau</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ECMP</kw>
        </keywords>
        <abstract><p>This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.</p></abstract>
        <draft>draft-ietf-intarea-flow-label-balancing-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC7098</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC7099</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC7100</doc-id>
        <title>Retirement of the "Internet Official Protocol Standards" Summary Document</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards".  It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</p></abstract>
        <draft>draft-resnick-retire-std1-01</draft>
        <obsoletes>
            <doc-id>RFC5000</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7100</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7101</doc-id>
        <title>List of Internet Official Protocol Standards: Replaced by a Web Page</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>December</month>
            <year>2013</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>At one time, the RFC Editor published snapshots of the "Internet Official Protocol Standards".  These documents were known as xx00 documents, the last of which was published in May 2008.  These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs.  As a result, the RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued.  Starting with the RFC number 7100, xx00 numbers will be available for assignment.</p></abstract>
        <draft>draft-rfced-rfcxx00-retired-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7101</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7102</doc-id>
        <title>Terms Used in Routing for Low-Power and Lossy Networks</title>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.</p></abstract>
        <draft>draft-ietf-roll-terminology-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC7102</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7103</doc-id>
        <title>Advice for Safe Handling of Malformed Messages</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <author>
            <name>G. Shapiro</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MTA</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications.  The malformed messages that result are non-standard.  Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant.  This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.</p></abstract>
        <draft>draft-ietf-appsawg-malformed-mail-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7103</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7104</doc-id>
        <title>Duplication Grouping Semantics in the Session Description Protocol</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>H. Ou</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>ssrc</kw>
            <kw>synchronization source</kw>
            <kw>grouping framework</kw>
        </keywords>
        <abstract><p>Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages.  This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers.  One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams.  This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP).  The semantics defined in this document are to be used with the SDP Grouping Framework.  Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.</p></abstract>
        <draft>draft-ietf-mmusic-duplication-grouping-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7104</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7105</doc-id>
        <title>Using Device-Provided Location-Related Measurements in Location Configuration Protocols</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>HELD</kw>
            <kw>Location</kw>
            <kw>Measurements</kw>
            <kw>Device-based</kw>
        </keywords>
        <abstract><p>This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information.  Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment.  A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device.  A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.</p></abstract>
        <draft>draft-ietf-geopriv-held-measurements-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7105</errata-url>
        <doi>10.17487/RFC7105</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7106</doc-id>
        <title>A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State</title>
        <author>
            <name>E. Ivov</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Conference Event Package</kw>
            <kw>service-uris</kw>
            <kw>conference-uris</kw>
            <kw>URI purpose</kw>
        </keywords>
        <abstract><p>This document defines and registers a value of "grouptextchat" ("Group Text Chat") for the URI &lt;purpose&gt; element of SIP's Conference Event Package.</p></abstract>
        <draft>draft-ivov-grouptextchat-purpose-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7106</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7107</doc-id>
        <title>Object Identifier Registry for the S/MIME Mail Security Working Group</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group.  This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.</p></abstract>
        <draft>draft-housley-smime-oids-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7107</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7108</doc-id>
        <title>A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>T. Manderson</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.</p><p> Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.</p><p> This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.</p></abstract>
        <draft>draft-jabley-dnsop-anycast-mapping-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7108</errata-url>
        <doi>10.17487/RFC7108</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7109</doc-id>
        <title>Flow Bindings Initiated by Home Agents for Mobile IPv6</title>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>D. Kim</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>F. Xia</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>MIPv6</kw>
            <kw>Flow mobility</kw>
        </keywords>
        <abstract><p>There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability.  In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6.  Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.</p></abstract>
        <draft>draft-yokota-mext-ha-init-flow-binding-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7109</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7110</doc-id>
        <title>Return Path Specified Label Switched Path (LSP) Ping</title>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>W. Cao</name>
        </author>
        <author>
            <name>S. Ning</name>
        </author>
        <author>
            <name>F. Jounay</name>
        </author>
        <author>
            <name>S. Delord</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Tunnel Stack</kw>
            <kw>Reply TC</kw>
        </keywords>
        <abstract><p>This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping".  These extensions allow a selection of the LSP to be used for the echo reply return path.  Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.</p></abstract>
        <draft>draft-ietf-mpls-return-path-specified-lsp-ping-15</draft>
        <updated-by>
            <doc-id>RFC7737</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7110</errata-url>
        <doi>10.17487/RFC7110</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7111</doc-id>
        <title>URI Fragment Identifiers for the text/csv Media Type</title>
        <author>
            <name>M. Hausenblas</name>
        </author>
        <author>
            <name>E. Wilde</name>
        </author>
        <author>
            <name>J. Tennison</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>mime</kw>
        </keywords>
        <abstract><p>This memo defines URI fragment identifiers for text/csv MIME entities.  These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell.  Fragment identification can use single items or ranges.</p></abstract>
        <draft>draft-hausenblas-csv-fragment-08</draft>
        <updates>
            <doc-id>RFC4180</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7111</errata-url>
        <doi>10.17487/RFC7111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7112</doc-id>
        <title>Implications of Oversized IPv6 Header Chains</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>The IPv6 specification allows IPv6 Header Chains of an arbitrary size.  The specification also allows options that can, in turn, extend each of the headers.  In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain.  This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.</p></abstract>
        <draft>draft-ietf-6man-oversized-header-chain-09</draft>
        <updates>
            <doc-id>RFC2460</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7112</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7113</doc-id>
        <title>Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages.  Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors.  However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers.  This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.</p></abstract>
        <draft>draft-ietf-v6ops-ra-guard-implementation-07</draft>
        <updates>
            <doc-id>RFC6105</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7113</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7114</doc-id>
        <title>Creation of a Registry for smime-type Parameter Values</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the Content-Type parameter "smime-type".  As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values.  This document creates the registry, registers the current values, and specifies the policies for registration of new values.</p></abstract>
        <draft>draft-leiba-smime-type-registry-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7114</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7115</doc-id>
        <title>Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations.  This document attempts to collect and present those that are most critical.  It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.</p></abstract>
        <draft>draft-ietf-sidr-origin-ops-23</draft>
        <is-also>
            <doc-id>BCP0185</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7115</errata-url>
        <doi>10.17487/RFC7115</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7116</doc-id>
        <title>Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries</title>
        <author>
            <name>K. Scott</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme).  Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type.  All of these fields are subject to a registry.  For the purpose of its research work, the group has created ad hoc registries.  As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management.  This document describes the necessary IANA actions.</p></abstract>
        <draft>draft-dtnrg-ltp-cbhe-registries-07</draft>
        <updated-by>
            <doc-id>RFC9758</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7116</errata-url>
        <doi>10.17487/RFC7116</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7117</doc-id>
        <title>Multicast in Virtual Private LAN Service (VPLS)</title>
        <author>
            <name>R. Aggarwal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Kamite</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>C. Kodeboniya</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <abstract><p>RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.</p><p> This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-mcast-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7117</errata-url>
        <doi>10.17487/RFC7117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7118</doc-id>
        <title>The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>I. Baz Castillo</name>
        </author>
        <author>
            <name>J. Millan Villegas</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>WebSocket</kw>
        </keywords>
        <abstract><p>The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications.  This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.</p></abstract>
        <draft>draft-ietf-sipcore-sip-websocket-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7118</errata-url>
        <doi>10.17487/RFC7118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7119</doc-id>
        <title>Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators</title>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>A. Kobayashi</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.</p></abstract>
        <draft>draft-ietf-ipfix-mediation-protocol-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC7119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7120</doc-id>
        <title>Early IANA Allocation of Standards Track Code Points</title>
        <author>
            <name>M. Cotton</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>early allocation</kw>
            <kw>policy</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply.  This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation.  The procedures in this document are intended to apply only to IETF Stream documents.</p></abstract>
        <draft>draft-cotton-rfc4020bis-02</draft>
        <obsoletes>
            <doc-id>RFC4020</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0100</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7120</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7121</doc-id>
        <title>High Availability within a Forwarding and Control Element Separation (ForCES) Network Element</title>
        <author>
            <name>K. Ogawa</name>
        </author>
        <author>
            <name>W. Wang</name>
        </author>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>HA</kw>
        </keywords>
        <abstract><p>This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE).  Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.</p></abstract>
        <draft>draft-ietf-forces-ceha-10</draft>
        <updates>
            <doc-id>RFC5810</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7391</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7121</errata-url>
        <doi>10.17487/RFC7121</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7122</doc-id>
        <title>Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)</title>
        <author>
            <name>H. Kruse</name>
        </author>
        <author>
            <name>S. Jero</name>
        </author>
        <author>
            <name>S. Ostermann</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams.  It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326).  UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed.  UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control.  DCCP addresses the congestion control problem, and its use is recommended whenever possible.  This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.</p></abstract>
        <draft>draft-irtf-dtnrg-dgram-clayer-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7122</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7123</doc-id>
        <title>Security Implications of IPv6 on IPv4 Networks</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.</p></abstract>
        <draft>draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC7123</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7124</doc-id>
        <title>Ethernet in the First Mile Copper (EFMCu) Interfaces MIB</title>
        <author>
            <name>E. Beili</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>EFM-CU-MIB</kw>
            <kw>ieee</kw>
        </keywords>
        <abstract><p>This document updates RFC 5066.  It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group.</p></abstract>
        <draft>draft-ietf-opsawg-rfc5066bis-07</draft>
        <updates>
            <doc-id>RFC5066</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7124</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7125</doc-id>
        <title>Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.</p></abstract>
        <draft>draft-trammell-ipfix-tcpcontrolbits-revision-05</draft>
        <obsoleted-by>
            <doc-id>RFC9565</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7125</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7126</doc-id>
        <title>Recommendations on Filtering of IPv4 Packets Containing IPv4 Options</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain.  Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.</p></abstract>
        <draft>draft-ietf-opsec-ip-options-filtering-07</draft>
        <is-also>
            <doc-id>BCP0186</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7126</errata-url>
        <doi>10.17487/RFC7126</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7127</doc-id>
        <title>Characterization of Proposed Standards</title>
        <author>
            <name>O. Kolkman</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Guidance</kw>
            <kw>Standards</kw>
            <kw>Standards Process</kw>
            <kw>Advancement</kw>
            <kw>Proposed Standard</kw>
        </keywords>
        <abstract><p>RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents.  This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.</p></abstract>
        <draft>draft-kolkman-proposed-standards-clarified-06</draft>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7128</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Router Implementation Report</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810.  The authors did not verify the accuracy of the information provided by respondents.  The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent.  The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.</p></abstract>
        <draft>draft-ietf-sidr-rpki-rtr-impl-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC7128</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7129</doc-id>
        <title>Authenticated Denial of Existence in the DNS</title>
        <author>
            <name>R. Gieben</name>
        </author>
        <author>
            <name>W. Mekking</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Internet</kw>
            <kw>DNSSEC</kw>
            <kw>Denial of Existence</kw>
            <kw>NSEC</kw>
            <kw>NSEC3</kw>
        </keywords>
        <abstract><p>Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.</p><p> This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.</p></abstract>
        <draft>draft-gieben-auth-denial-of-existence-dns-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7129</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7130</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces</title>
        <author>
            <name>M. Bhatia</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Chen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Boutros</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Binderberger</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Haas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link.</p><p> This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.</p></abstract>
        <draft>draft-ietf-bfd-on-lags-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7130</errata-url>
        <doi>10.17487/RFC7130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7131</doc-id>
        <title>Session Initiation Protocol (SIP) History-Info Header Call Flow Examples</title>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <author>
            <name>S. Schubert</name>
        </author>
        <author>
            <name>H. van Elburg</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>History-Info</kw>
            <kw>RFC4244bis</kw>
            <kw>Example</kw>
            <kw>Call Flow</kw>
        </keywords>
        <abstract><p>This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted.  The use cases are described along with the corresponding call flow diagrams and messaging details.</p></abstract>
        <draft>draft-ietf-sipcore-rfc4244bis-callflows-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC7131</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7132</doc-id>
        <title>Threat Model for BGP Path Security</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>A. Chi</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>BGPSEC</kw>
            <kw>RPKI</kw>
            <kw>SIDR</kw>
        </keywords>
        <abstract><p>This document describes a threat model for the context in which External Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI) and focuses on the ability of an Autonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI.</p><p> The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.</p></abstract>
        <draft>draft-ietf-sidr-bgpsec-threats-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7132</errata-url>
        <doi>10.17487/RFC7132</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7133</doc-id>
        <title>Information Elements for Data Link Layer Traffic Measurement</title>
        <author>
            <name>S. Kashima</name>
        </author>
        <author>
            <name>A. Kobayashi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>PSAMP</kw>
            <kw>Provider Bridge</kw>
            <kw>Provider Backbone Bridge</kw>
            <kw>ipfix</kw>
        </keywords>
        <abstract><p>This document describes Information Elements related to the data link layer.  They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.</p></abstract>
        <draft>draft-ietf-ipfix-data-link-layer-monitoring-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC7133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7134</doc-id>
        <title>The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review"</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>2</page-count>
        <keywords>
            <kw>Resource-Priority Namespaces</kw>
            <kw>Resource-Priority Priority-values</kw>
        </keywords>
        <abstract><p>RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries.  The management policy of these registries is "Standards Action".  This document normatively updates RFC 4412 to change the management policy of these registries to "IETF Review".</p></abstract>
        <draft>draft-rosen-rph-reg-policy-01</draft>
        <updates>
            <doc-id>RFC4412</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC7134</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7135</doc-id>
        <title>Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications</title>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace 'esnet' and registers this namespace with IANA.  The new header field namespace allows for local emergency session establishment to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.</p></abstract>
        <draft>draft-polk-local-emergency-rph-namespace-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7135</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7136</doc-id>
        <title>Significance of IPv6 Interface Identifiers</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses.  Interface identifiers are formed by a variety of methods.  This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value.  In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier.  This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.</p></abstract>
        <draft>draft-ietf-6man-ug-06</draft>
        <updates>
            <doc-id>RFC4291</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7136</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7137</doc-id>
        <title>Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks</title>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>S. Ratliff</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.</p><p> This document updates RFC 5820.</p></abstract>
        <draft>draft-ietf-ospf-manet-single-hop-or-04</draft>
        <updates>
            <doc-id>RFC5820</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7137</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7138</doc-id>
        <title>Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks</title>
        <author>
            <name>D. Ceccarelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>S. Belotti</name>
        </author>
        <author>
            <name>R. Rao</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>GMPLS</kw>
            <kw>G709</kw>
            <kw>OTN</kw>
        </keywords>
        <abstract><p>This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012.  It extends mechanisms defined in RFC 4203.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-ospf-g709v3-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7138</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7139</doc-id>
        <title>GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks</title>
        <author>
            <name>F. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zhang</name>
        </author>
        <author>
            <name>S. Belotti</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>K. Pithewan</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.</p><p> This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-signaling-g709v3-12</draft>
        <updates>
            <doc-id>RFC4328</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7892</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7139</errata-url>
        <doi>10.17487/RFC7139</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7140</doc-id>
        <title>LDP Extensions for Hub and Spoke Multipoint Label Switched Path</title>
        <author>
            <name>L. Jin</name>
        </author>
        <author>
            <name>F. Jounay</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>P2MP LSP</kw>
            <kw>MP2MP LSP</kw>
        </keywords>
        <abstract><p>This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path.  That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node.  Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root.  Direct communication among the leaf nodes is not allowed.</p></abstract>
        <draft>draft-ietf-mpls-mldp-hsmp-06</draft>
        <updated-by>
            <doc-id>RFC7358</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7140</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7141</doc-id>
        <title>Byte and Packet Congestion Notification</title>
        <author>
            <name>B. Briscoe</name>
        </author>
        <author>
            <name>J. Manner</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>active queue management</kw>
            <kw>aqm</kw>
            <kw>availability</kw>
            <kw>denial of service</kw>
            <kw>dos</kw>
            <kw>quality of service</kw>
            <kw>qos</kw>
            <kw>congestion control</kw>
            <kw>fairness</kw>
            <kw>incentives</kw>
            <kw>architecture layering</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract><p>This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced).  We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used.  This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.</p></abstract>
        <draft>draft-ietf-tsvwg-byte-pkt-congest-12</draft>
        <updates>
            <doc-id>RFC2309</doc-id>
            <doc-id>RFC2914</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0041</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7141</errata-url>
        <doi>10.17487/RFC7141</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7142</doc-id>
        <title>Reclassification of RFC 1142 to Historic</title>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain Routing Protocol", to Historic status.  This memo also obsoletes RFC 1142.</p></abstract>
        <draft>draft-ietf-isis-rfc1142-to-historic-00</draft>
        <obsoletes>
            <doc-id>RFC1142</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7142</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7143</doc-id>
        <title>Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)</title>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <author>
            <name>J. Satran</name>
        </author>
        <author>
            <name>K. Meth</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>295</page-count>
        <keywords>
            <kw>iSCSI</kw>
            <kw>SCSI</kw>
            <kw>storage</kw>
            <kw>SAN</kw>
            <kw>block storage</kw>
            <kw>SCSI object storage devices</kw>
            <kw>OSD</kw>
            <kw>SAM</kw>
            <kw>disk</kw>
            <kw>T10</kw>
        </keywords>
        <abstract><p>This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.</p><p> This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.</p></abstract>
        <draft>draft-ietf-storm-iscsi-cons-10</draft>
        <obsoletes>
            <doc-id>RFC3720</doc-id>
            <doc-id>RFC3980</doc-id>
            <doc-id>RFC4850</doc-id>
            <doc-id>RFC5048</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3721</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC7143</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7144</doc-id>
        <title>Internet Small Computer System Interface (iSCSI) SCSI Features Update</title>
        <author>
            <name>F. Knight</name>
        </author>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP.  The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols.  This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5.</p></abstract>
        <draft>draft-ietf-storm-iscsi-sam-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC7144</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7145</doc-id>
        <title>Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification</title>
        <author>
            <name>M. Ko</name>
        </author>
        <author>
            <name>A. Nezhinsky</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <abstract><p>Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.</p><p> This document obsoletes RFC 5046.</p></abstract>
        <draft>draft-ietf-storm-iser-15</draft>
        <obsoletes>
            <doc-id>RFC5046</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC7145</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7146</doc-id>
        <title>Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>P. Koning</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>IPsec</kw>
        </keywords>
        <abstract><p>RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP).  This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.</p></abstract>
        <draft>draft-ietf-storm-ipsec-ips-update-04</draft>
        <updates>
            <doc-id>RFC3720</doc-id>
            <doc-id>RFC3723</doc-id>
            <doc-id>RFC3821</doc-id>
            <doc-id>RFC3822</doc-id>
            <doc-id>RFC4018</doc-id>
            <doc-id>RFC4172</doc-id>
            <doc-id>RFC4173</doc-id>
            <doc-id>RFC4174</doc-id>
            <doc-id>RFC5040</doc-id>
            <doc-id>RFC5041</doc-id>
            <doc-id>RFC5042</doc-id>
            <doc-id>RFC5043</doc-id>
            <doc-id>RFC5044</doc-id>
            <doc-id>RFC5045</doc-id>
            <doc-id>RFC5046</doc-id>
            <doc-id>RFC5047</doc-id>
            <doc-id>RFC5048</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC7146</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7147</doc-id>
        <title>Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI)</title>
        <author>
            <name>M. Bakke</name>
        </author>
        <author>
            <name>P. Venkatesen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>ISCSI-MIB</kw>
        </keywords>
        <abstract><p>This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP).</p><p> This document obsoletes RFC 4544.</p></abstract>
        <draft>draft-ietf-storm-iscsimib-04</draft>
        <obsoletes>
            <doc-id>RFC4544</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <doi>10.17487/RFC7147</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7148</doc-id>
        <title>Prefix Delegation Support for Proxy Mobile IPv6</title>
        <author>
            <name>X. Zhou</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>C. Williams</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Prefix Delegation</kw>
            <kw>Proxy Mobile IPv6</kw>
            <kw>PMIPv6</kw>
            <kw>Mobile Router</kw>
        </keywords>
        <abstract><p>This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation.  Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address.  Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.</p></abstract>
        <draft>draft-ietf-netext-pd-pmip-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7148</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7149</doc-id>
        <title>Software-Defined Networking: A Perspective from within a Service Provider Environment</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Network Automation</kw>
            <kw>Policy Management</kw>
            <kw>Connectivity Provisioning</kw>
            <kw>Service Parameter Exposure</kw>
            <kw>Dynamic Negotiation</kw>
            <kw>Dynamic Service Provisioning</kw>
            <kw>Autonomic</kw>
            <kw>Programmable Networks</kw>
        </keywords>
        <abstract><p>Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.</p><p> It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.</p></abstract>
        <draft>draft-sin-sdnrg-sdn-approach-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7149</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7150</doc-id>
        <title>Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol</title>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.</p><p> This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.</p></abstract>
        <draft>draft-ietf-pce-vendor-constraints-11</draft>
        <obsoleted-by>
            <doc-id>RFC7470</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7150</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7151</doc-id>
        <title>File Transfer Protocol HOST Command for Virtual Hosts</title>
        <author>
            <name>P. Hethmon</name>
        </author>
        <author>
            <name>R. McMurray</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>FTP</kw>
            <kw>HOST</kw>
        </keywords>
        <abstract><p>The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address.  This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.</p></abstract>
        <draft>draft-hethmon-mcmurray-ftpext-ftp-hosts-05</draft>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7151</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7152</doc-id>
        <title>Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)</title>
        <author>
            <name>R. Key</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. DeLord</name>
        </author>
        <author>
            <name>F. Jounay</name>
        </author>
        <author>
            <name>L. Huang</name>
        </author>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>M. Paul</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RMP</kw>
            <kw>Rooted-Multipoint</kw>
            <kw>VPLS</kw>
            <kw>Virtual Private LAN Service</kw>
            <kw>E-VPN</kw>
            <kw>Ethernet Virtual Private Network</kw>
            <kw>MPLS</kw>
            <kw>Multi-Protocol Label Switching</kw>
            <kw>CE</kw>
            <kw>Carrier Ethernet</kw>
        </keywords>
        <abstract><p>This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply "L2VPN").  It is intended that potential solutions will use these requirements as guidelines.</p></abstract>
        <draft>draft-ietf-l2vpn-etree-reqt-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC7152</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7153</doc-id>
        <title>IANA Registries for BGP Extended Communities</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Border Gateway Protocol</kw>
        </keywords>
        <abstract><p>This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute.  This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries.  This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries.  These changes are compatible with the existing allocations and thus do not affect protocol implementations.  The changes will, however, impact the "IANA Considerations" sections of future protocol specifications.  This document updates RFC 4360 and RFC 5701.</p></abstract>
        <draft>draft-ietf-idr-extcomm-iana-02</draft>
        <updates>
            <doc-id>RFC4360</doc-id>
            <doc-id>RFC5701</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9184</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7154</doc-id>
        <title>IETF Guidelines for Conduct</title>
        <author>
            <name>S. Moonesamy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.</p><p> This document is an updated version of the guidelines for conduct originally published in RFC 3184.</p></abstract>
        <draft>draft-moonesamy-ietf-conduct-3184bis-07</draft>
        <obsoletes>
            <doc-id>RFC3184</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0054</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7154</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7155</doc-id>
        <title>Diameter Network Access Server Application</title>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>70</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>Authentication</kw>
            <kw>Authorization</kw>
            <kw>Accounting</kw>
            <kw>Remote Access</kw>
        </keywords>
        <abstract><p>This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment; it obsoletes RFC 4005.  When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.</p></abstract>
        <draft>draft-ietf-dime-rfc4005bis-14</draft>
        <obsoletes>
            <doc-id>RFC4005</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7155</errata-url>
        <doi>10.17487/RFC7155</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7156</doc-id>
        <title>Diameter Support for Proxy Mobile IPv6 Localized Routing</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing.  The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA.  In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized.  This document specifies how to accomplish this using the Diameter protocol.</p></abstract>
        <draft>draft-ietf-dime-pmip6-lr-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7156</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7157</doc-id>
        <title>IPv6 Multihoming without Network Address Translation</title>
        <author>
            <name>O. Troan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Miles</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>T. Okimoto</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>NPTv6</kw>
        </keywords>
        <abstract><p>Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution.  For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6).  However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity.  In this document, we analyze the use cases of multihoming.  We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria.  We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7157</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7158</doc-id>
        <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
        <author>
            <name>T. Bray</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</p><p> This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</p></abstract>
        <draft>draft-ietf-json-rfc4627bis-10</draft>
        <obsoleted-by>
            <doc-id>RFC7159</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>json</wg_acronym>
        <doi>10.17487/RFC7158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7159</doc-id>
        <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
        <author>
            <name>T. Bray</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</p><p> This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</p></abstract>
        <draft>draft-ietf-json-rfc4627bis-rfc7159bis</draft>
        <obsoletes>
            <doc-id>RFC4627</doc-id>
            <doc-id>RFC7158</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8259</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>json</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7159</errata-url>
        <doi>10.17487/RFC7159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7160</doc-id>
        <title>Support for Multiple Clock Rates in an RTP Session</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <author>
            <name>G. Zorn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document clarifies the RTP specification regarding the use of different clock rates in an RTP session.  It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document.  It updates RFC 3550.</p></abstract>
        <draft>draft-ietf-avtext-multiple-clock-rates-11</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC7160</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7161</doc-id>
        <title>Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)</title>
        <author>
            <name>LM. Contreras</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>I. Soto</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>PMIPv6</kw>
            <kw>Proxy Mobile IPv6</kw>
            <kw>multicast</kw>
            <kw>handover</kw>
            <kw>SIAL</kw>
        </keywords>
        <abstract><p>This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers.  The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways.  To do that, extensions to the current PMIPv6 protocol are proposed.  These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem.  Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).</p></abstract>
        <draft>draft-ietf-multimob-handover-optimization-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>multimob</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7161</errata-url>
        <doi>10.17487/RFC7161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7162</doc-id>
        <title>IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>D. Cridland</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>CONDSTORE</kw>
            <kw>QRESYNC</kw>
            <kw>VANISHED</kw>
            <kw>EXPUNGE</kw>
            <kw>quick resynchronization</kw>
        </keywords>
        <abstract><p>Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.</p><p> Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.</p><p> This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.</p><p> Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.</p></abstract>
        <draft>draft-ietf-qresync-rfc5162bis-10</draft>
        <obsoletes>
            <doc-id>RFC4551</doc-id>
            <doc-id>RFC5162</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2683</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>qresync</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7162</errata-url>
        <doi>10.17487/RFC7162</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7163</doc-id>
        <title>URN for Country-Specific Emergency Services</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>I. Sedlacek</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>sip</kw>
            <kw>emergency</kw>
            <kw>urn</kw>
            <kw>country</kw>
            <kw>5031</kw>
            <kw>sos</kw>
        </keywords>
        <abstract><p>This document updates the registration guidance provided in Section 4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries".  This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.</p></abstract>
        <draft>draft-ietf-ecrit-country-emg-urn-03</draft>
        <updates>
            <doc-id>RFC5031</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC7163</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7164</doc-id>
        <title>RTP and Leap Seconds</title>
        <author>
            <name>K. Gross</name>
        </author>
        <author>
            <name>R. Brandenburg</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Leap second</kw>
            <kw>rtp</kw>
            <kw>Real-time Transport Protocol</kw>
            <kw>ntp</kw>
            <kw>Network Time Protocol</kw>
            <kw>UTC</kw>
            <kw>Universal Coordinated Time</kw>
            <kw>tai</kw>
            <kw>International Atomic Time</kw>
            <kw>Unix time</kw>
        </keywords>
        <abstract><p>This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds.  It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.</p></abstract>
        <draft>draft-ietf-avtcore-leap-second-08</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7164</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7165</doc-id>
        <title>Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>JWS</kw>
            <kw>JWE</kw>
            <kw>JWK</kw>
            <kw>JWA</kw>
            <kw>JWT</kw>
            <kw>CMS</kw>
            <kw>S/MIME</kw>
            <kw>JOSE</kw>
            <kw>XMPP</kw>
            <kw>ALTO</kw>
            <kw>OAuth</kw>
        </keywords>
        <abstract><p>Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer.  For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1.  Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON).  This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.</p></abstract>
        <draft>draft-ietf-jose-use-cases-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <doi>10.17487/RFC7165</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7166</doc-id>
        <title>Supporting Authentication Trailer for OSPFv3</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.</p><p> The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.</p></abstract>
        <draft>draft-ietf-ospf-rfc6506bis-05</draft>
        <obsoletes>
            <doc-id>RFC6506</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7166</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7167</doc-id>
        <title>A Framework for Point-to-Multipoint MPLS in Transport Networks</title>
        <author>
            <name>D. Frost</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>mpls-tp</kw>
            <kw>mpls</kw>
        </keywords>
        <abstract><p>The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks.  The MPLS-TP supports both point-to-point and point-to-multipoint transport paths.  This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths.</p></abstract>
        <draft>draft-ietf-mpls-tp-p2mp-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7167</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7168</doc-id>
        <title>The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)</title>
        <author>
            <name>I. Nazar</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity.  This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.</p></abstract>
        <draft>draft-nazar-htcpcp-tea-00</draft>
        <updates>
            <doc-id>RFC2324</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7169</doc-id>
        <title>The NSA (No Secrecy Afforded) Certificate Extension</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates.  Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained.  In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party.  Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.</p></abstract>
        <draft>draft-turner-no-secrecy-afforded-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7169</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7170</doc-id>
        <title>Tunnel Extensible Authentication Protocol (TEAP) Version 1</title>
        <author>
            <name>H. Zhou</name>
        </author>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>S. Hanna</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>Tunnel</kw>
        </keywords>
        <abstract><p>This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel.  Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.</p></abstract>
        <draft>draft-ietf-emu-eap-tunnel-method-10</draft>
        <updated-by>
            <doc-id>RFC9427</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7170</errata-url>
        <doi>10.17487/RFC7170</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7171</doc-id>
        <title>PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods</title>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>P. Sangster</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>NEA EAP</kw>
        </keywords>
        <abstract><p>This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS).  The document also describes the intended applicability of PT-EAP.</p></abstract>
        <draft>draft-ietf-nea-pt-eap-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>nea</wg_acronym>
        <doi>10.17487/RFC7171</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7172</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>P. Agarwal</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>VLAN</kw>
            <kw>Fine-Grained</kw>
            <kw>Label</kw>
        </keywords>
        <abstract><p>The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count.  The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs.  However, there are applications that require a larger number of labels providing configurable isolation of data.  This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this.  These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.</p></abstract>
        <draft>draft-ietf-trill-fine-labeling-07</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7172</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7173</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires</title>
        <author>
            <name>L. Yong</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>J. Hudson</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>pseudowires</kw>
            <kw>MPLS</kw>
            <kw>RBridge</kw>
        </keywords>
        <abstract><p>This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.</p></abstract>
        <draft>draft-ietf-trill-o-pw-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7173</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7174</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework</title>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>RBridge</kw>
            <kw>CFM</kw>
            <kw>BFD</kw>
            <kw>MEP</kw>
            <kw>MIP</kw>
            <kw>MA</kw>
            <kw>Fault</kw>
            <kw>Performance</kw>
            <kw>Maintenance</kw>
            <kw>Continuity</kw>
            <kw>Connectivity</kw>
            <kw>Delay</kw>
            <kw>Operations</kw>
            <kw>Administration</kw>
        </keywords>
        <abstract><p>This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks.  The focus of the document is on the fault and performance management aspects of TRILL OAM.</p></abstract>
        <draft>draft-ietf-trill-oam-framework-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7174</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7175</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support</title>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RBridge</kw>
            <kw>Echo</kw>
            <kw>one-hop</kw>
        </keywords>
        <abstract><p>This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.</p><p> BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.</p></abstract>
        <draft>draft-ietf-trill-rbridge-bfd-07</draft>
        <updated-by>
            <doc-id>RFC8564</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7175</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7176</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>Affinity</kw>
            <kw>multicast</kw>
            <kw>multi-topology</kw>
            <kw>fine-grained</kw>
            <kw>VLAN</kw>
        </keywords>
        <abstract><p>The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic.  This document specifies the data formats and code points for the IS-IS extensions to support TRILL.  These data formats and code points may also be used by technologies other than TRILL.  This document obsoletes RFC 6326.</p></abstract>
        <draft>draft-ietf-isis-rfc6326bis-03</draft>
        <obsoletes>
            <doc-id>RFC6326</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7176</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7177</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Adjacency</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>H. Yang</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>RBridge</kw>
            <kw>TRILL</kw>
            <kw>Adjacency</kw>
            <kw>BFD</kw>
            <kw>p2p</kw>
            <kw>point-to-point</kw>
        </keywords>
        <abstract><p>The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached.  TRILL uses Intermediate System to Intermediate System (IS-IS) routing.  This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges).  It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency.  State diagrams are included where appropriate.  This document obsoletes RFC 6327 and updates RFC 6325.</p></abstract>
        <draft>draft-ietf-trill-rfc6327bis-04</draft>
        <obsoletes>
            <doc-id>RFC6327</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7780</doc-id>
            <doc-id>RFC8139</doc-id>
            <doc-id>RFC8249</doc-id>
            <doc-id>RFC8377</doc-id>
            <doc-id>RFC8564</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7177</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7178</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>native</kw>
        </keywords>
        <abstract><p>This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.</p></abstract>
        <draft>draft-ietf-trill-rbridge-channel-08</draft>
        <updated-by>
            <doc-id>RFC7978</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7178</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7179</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Header Extension</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>C. Bestler</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RBridge</kw>
            <kw>extension</kw>
            <kw>option</kw>
        </keywords>
        <abstract><p>The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions.  This document specifies an initial extension providing additional flag bits and specifies some of those bits.  It updates RFC 6325.</p></abstract>
        <draft>draft-ietf-trill-rbridge-extension-05</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7780</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7179</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7180</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>RBridge</kw>
            <kw>IS-IS</kw>
            <kw>reachability</kw>
            <kw>overload</kw>
            <kw>MTU</kw>
            <kw>DEI</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.</p><p> RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.</p></abstract>
        <draft>draft-ietf-trill-clear-correct-06</draft>
        <obsoleted-by>
            <doc-id>RFC7780</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6325</doc-id>
            <doc-id>RFC6327</doc-id>
            <doc-id>RFC6439</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7180</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7181</doc-id>
        <title>The Optimized Link State Routing Protocol Version 2</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>P. Jacquet</name>
        </author>
        <author>
            <name>U. Herberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>115</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>ad hoc network</kw>
            <kw>NHDP</kw>
        </keywords>
        <abstract><p>This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).</p></abstract>
        <draft>draft-ietf-manet-olsrv2-19</draft>
        <updated-by>
            <doc-id>RFC7183</doc-id>
            <doc-id>RFC7187</doc-id>
            <doc-id>RFC7188</doc-id>
            <doc-id>RFC7466</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7181</errata-url>
        <doi>10.17487/RFC7181</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7182</doc-id>
        <title>Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)</title>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>NHDP</kw>
            <kw>OLSRv2</kw>
            <kw>security</kw>
            <kw>integrity</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document revises, extends, and replaces RFC 6622.  It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444.  It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.</p></abstract>
        <draft>draft-ietf-manet-rfc6622-bis-06</draft>
        <obsoletes>
            <doc-id>RFC6622</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7182</errata-url>
        <doi>10.17487/RFC7182</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7183</doc-id>
        <title>Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)</title>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>OLSRv2</kw>
            <kw>Security</kw>
            <kw>Integrity protection</kw>
            <kw>ICV</kw>
        </keywords>
        <abstract><p>This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.</p><p> The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.</p><p> This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.</p></abstract>
        <draft>draft-ietf-manet-nhdp-olsrv2-sec-05</draft>
        <updates>
            <doc-id>RFC6130</doc-id>
            <doc-id>RFC7181</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7183</errata-url>
        <doi>10.17487/RFC7183</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7184</doc-id>
        <title>Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2</title>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>Routing</kw>
            <kw>MANET</kw>
            <kw>Optimized Link STate Routing Protocol version 2</kw>
        </keywords>
        <abstract><p>This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing Protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications.  This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol.  Two levels of compliance allow this MIB module to be deployed on constrained routers.</p></abstract>
        <draft>draft-ietf-manet-olsrv2-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7184</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7185</doc-id>
        <title>Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>P. Jacquet</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>ad hoc network</kw>
            <kw>proactive</kw>
            <kw>NHDP</kw>
            <kw>neighborhood discovery</kw>
            <kw>OLSR</kw>
            <kw>OLSRv2</kw>
            <kw>routing protocol</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract><p>The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes.  This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.</p></abstract>
        <draft>draft-ietf-manet-olsrv2-metrics-rationale-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7185</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7186</doc-id>
        <title>Security Threats for the Neighborhood Discovery Protocol (NHDP)</title>
        <author>
            <name>J. Yi</name>
        </author>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP.  This document is not intended to propose solutions to the threats described.</p></abstract>
        <draft>draft-ietf-manet-nhdp-sec-threats-06</draft>
        <updated-by>
            <doc-id>RFC7985</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7186</errata-url>
        <doi>10.17487/RFC7186</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7187</doc-id>
        <title>Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays.  The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.</p></abstract>
        <draft>draft-ietf-manet-olsrv2-rmpr-optimization-01</draft>
        <updates>
            <doc-id>RFC7181</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7187</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7188</doc-id>
        <title>Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>OLSRv2</kw>
            <kw>NHDP</kw>
            <kw>TLV</kw>
        </keywords>
        <abstract><p>This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions.  This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).</p></abstract>
        <draft>draft-ietf-manet-nhdp-olsrv2-tlv-extension-05</draft>
        <updates>
            <doc-id>RFC6130</doc-id>
            <doc-id>RFC7181</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7722</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7188</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7189</doc-id>
        <title>Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PW VCCV</kw>
            <kw>MPLS-TP CC/CV/RDI</kw>
        </keywords>
        <abstract><p>This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs.  This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.</p></abstract>
        <draft>draft-ietf-pwe3-mpls-tp-cv-adv-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7189</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7190</doc-id>
        <title>Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)</title>
        <author>
            <name>C. Villamizar</name>
        </author>
        <date>
            <month>March</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>composite link</kw>
            <kw>link aggregation</kw>
            <kw>ECMP</kw>
            <kw>link bundling</kw>
            <kw>multipath</kw>
            <kw>MPLS-TP</kw>
        </keywords>
        <abstract><p>Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.</p><p> Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.</p></abstract>
        <draft>draft-ietf-mpls-multipath-use-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7191</doc-id>
        <title>Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors.  The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages.  The key package error content type is used to indicate an error occurred during the processing of a key package.  CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.</p></abstract>
        <draft>draft-housley-ct-keypackage-receipt-n-error-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7191</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7192</doc-id>
        <title>Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Key Package</kw>
            <kw>Key Package Receipt</kw>
            <kw>Key Package Error</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types.  Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.</p></abstract>
        <draft>draft-turner-ct-keypackage-receipt-n-error-algs-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7192</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7193</doc-id>
        <title>The application/cms Media Type</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Cryptographic Message Syntax</kw>
        </keywords>
        <abstract><p>This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.</p></abstract>
        <draft>draft-turner-application-cms-media-type-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7193</errata-url>
        <doi>10.17487/RFC7193</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7194</doc-id>
        <title>Default Port for Internet Relay Chat (IRC) via TLS/SSL</title>
        <author>
            <name>R. Hartmann</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.</p></abstract>
        <draft>draft-hartmann-default-port-for-irc-via-tls-ssl-09</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7194</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7195</doc-id>
        <title>Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>S. Veikkolainen</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>PSTN</kw>
        </keywords>
        <abstract><p>This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).</p></abstract>
        <draft>draft-ietf-mmusic-sdp-cs-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7195</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7196</doc-id>
        <title>Making Route Flap Damping Usable</title>
        <author>
            <name>C. Pelsser</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>O. Maennel</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>rfd</kw>
        </keywords>
        <abstract><p>Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers.  Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged.  Many operators have turned RFD off.  Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD.  The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.</p></abstract>
        <draft>draft-ietf-idr-rfd-usable-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7196</errata-url>
        <doi>10.17487/RFC7196</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7197</doc-id>
        <title>Duplication Delay Attribute in the Session Description Protocol</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>H. Ou</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Interleaving</kw>
            <kw>temporal diversity</kw>
            <kw>temporal redundancy</kw>
            <kw>time shifted</kw>
            <kw>delayed duplication</kw>
        </keywords>
        <abstract><p>A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units.  This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication".  This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.</p></abstract>
        <draft>draft-ietf-mmusic-delayed-duplication-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7197</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7198</doc-id>
        <title>Duplicating RTP Streams</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RTP duplication</kw>
            <kw>live/live</kw>
            <kw>redundancy</kw>
        </keywords>
        <abstract><p>Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages.  In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets.  In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage.  For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements.  This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.</p></abstract>
        <draft>draft-ietf-avtext-rtp-duplication-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC7198</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7199</doc-id>
        <title>Location Configuration Extensions for Policy Management</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>geopriv</kw>
            <kw>geolocation</kw>
            <kw>privacy</kw>
            <kw>policy</kw>
        </keywords>
        <abstract><p>Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location.  These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute.  This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.</p></abstract>
        <draft>draft-ietf-geopriv-policy-uri-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC7199</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7200</doc-id>
        <title>A Session Initiation Protocol (SIP) Load-Control Event Package</title>
        <author>
            <name>C. Shen</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>A. Koike</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Overload Control</kw>
            <kw>Server</kw>
            <kw>Performance</kw>
        </keywords>
        <abstract><p>This specification defines a load-control event package for the Session Initiation Protocol (SIP).  It allows SIP entities to distribute load-filtering policies to other SIP entities in the network.  The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix.  The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.</p></abstract>
        <draft>draft-ietf-soc-load-control-event-package-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>soc</wg_acronym>
        <doi>10.17487/RFC7200</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7201</doc-id>
        <title>Options for Securing RTP Sessions</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Secure RTP</kw>
            <kw>SRTP</kw>
            <kw>key management</kw>
            <kw>real-time</kw>
            <kw>media</kw>
        </keywords>
        <abstract><p>The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments.  This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments.  The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism.  This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-security-options-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7201</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7202</doc-id>
        <title>Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SRTP</kw>
            <kw>RTP Profile</kw>
            <kw>Payload Format</kw>
        </keywords>
        <abstract><p>This memo discusses the problem of securing real-time multimedia sessions.  It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism.  This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.</p></abstract>
        <draft>draft-ietf-avt-srtp-not-mandatory-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7202</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7203</doc-id>
        <title>An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information</title>
        <author>
            <name>T. Takahashi</name>
        </author>
        <author>
            <name>K. Landfield</name>
        </author>
        <author>
            <name>Y. Kadobayashi</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>data structure</kw>
            <kw>information architecture</kw>
            <kw>incident response</kw>
            <kw>response team</kw>
            <kw>security incident</kw>
            <kw>information exchange</kw>
            <kw>knowledge sharing</kw>
            <kw>security operation</kw>
            <kw>automation</kw>
            <kw>vulnerability</kw>
            <kw>CERT</kw>
            <kw>CSIRT</kw>
        </keywords>
        <abstract><p>This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations.  It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.</p></abstract>
        <draft>draft-ietf-mile-sci-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7203</errata-url>
        <doi>10.17487/RFC7203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7204</doc-id>
        <title>Requirements for Labeled NFS</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2).  It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system.  The intent here is not to present the protocol changes but to describe the environment in which they reside.</p></abstract>
        <draft>draft-ietf-nfsv4-labreqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7205</doc-id>
        <title>Use Cases for Telepresence Multistreams</title>
        <author>
            <name>A. Romanow</name>
        </author>
        <author>
            <name>S. Botzko</name>
        </author>
        <author>
            <name>M. Duckworth</name>
        </author>
        <author>
            <name>R. Even</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co-located presence through multimedia communication that includes at least audio and video signals of high fidelity.  A number of techniques for handling audio and video streams are used to create this experience.  When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible.  Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork.  This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference.</p></abstract>
        <draft>draft-ietf-clue-telepresence-use-cases-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC7205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7206</doc-id>
        <title>Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>L. Liess</name>
        </author>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks.  This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.</p></abstract>
        <draft>draft-ietf-insipid-session-id-reqts-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>insipid</wg_acronym>
        <doi>10.17487/RFC7206</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7207</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for Eurosystem Messaging</title>
        <author>
            <name>M. Ortseifen</name>
        </author>
        <author>
            <name>G. Dickfeld</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>URN Namespace</kw>
            <kw>Eurosystem</kw>
            <kw>TARGET2</kw>
            <kw>TARGET2-Securities</kw>
            <kw>ESCB</kw>
        </keywords>
        <abstract><p>This document defines and registers with IANA a Uniform Resource Name (URN) namespace for usage within messages standardized by the Eurosystem.  The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).</p></abstract>
        <draft>draft-bundesbank-eurosystem-namespace-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7208</doc-id>
        <title>Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1</title>
        <author>
            <name>S. Kitterman</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>spoofing</kw>
            <kw>spf</kw>
            <kw>anti-forgery</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.</p><p> This document obsoletes RFC 4408.</p></abstract>
        <draft>draft-ietf-spfbis-4408bis-21</draft>
        <obsoletes>
            <doc-id>RFC4408</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7372</doc-id>
            <doc-id>RFC8553</doc-id>
            <doc-id>RFC8616</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>spfbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7208</errata-url>
        <doi>10.17487/RFC7208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7209</doc-id>
        <title>Requirements for Ethernet VPN (EVPN)</title>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>A. Isaac</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ethernet l2vpn</kw>
        </keywords>
        <abstract><p>The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution.  In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames.  Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration.  This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.</p></abstract>
        <draft>draft-ietf-l2vpn-evpn-req-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7209</errata-url>
        <doi>10.17487/RFC7209</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7210</doc-id>
        <title>Database of Long-Lived Symmetric Cryptographic Keys</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security.  The database is designed to support both manual and automated key management.  In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database.  In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.</p></abstract>
        <draft>draft-ietf-karp-crypto-key-table-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>karp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7210</errata-url>
        <doi>10.17487/RFC7210</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7211</doc-id>
        <title>Operations Model for Router Keying</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".  Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts.  This document gives recommendations to operators and implementors regarding management and operation of router authentication.  These recommendations will also assist protocol designers in understanding management issues they will face.</p></abstract>
        <draft>draft-ietf-karp-ops-model-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>karp</wg_acronym>
        <doi>10.17487/RFC7211</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7212</doc-id>
        <title>MPLS Generic Associated Channel (G-ACh) Advertisement Protocol</title>
        <author>
            <name>D. Frost</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow.  These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel.  This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information.  This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.</p></abstract>
        <draft>draft-ietf-mpls-gach-adv-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7212</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7213</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing</title>
        <author>
            <name>D. Frost</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MPLS</kw>
        </keywords>
        <abstract><p>The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.  This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.</p></abstract>
        <draft>draft-ietf-mpls-tp-ethernet-addressing-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7214</doc-id>
        <title>Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586.</p><p> This document also updates RFCs 6374, 6378, 6427, and 6428.</p></abstract>
        <draft>draft-ietf-mpls-moving-iana-registries-04</draft>
        <updates>
            <doc-id>RFC5586</doc-id>
            <doc-id>RFC6374</doc-id>
            <doc-id>RFC6378</doc-id>
            <doc-id>RFC6427</doc-id>
            <doc-id>RFC6428</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7214</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7215</doc-id>
        <title>Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations</title>
        <author>
            <name>L. Jakab</name>
        </author>
        <author>
            <name>A. Cabellos-Aparicio</name>
        </author>
        <author>
            <name>F. Coras</name>
        </author>
        <author>
            <name>J. Domingo-Pascual</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>LISP</kw>
            <kw>deployment</kw>
        </keywords>
        <abstract><p>This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios.  It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013.  LISP deployment scenarios may have evolved since then.  This memo represents one stable point in that evolution of understanding.</p></abstract>
        <draft>draft-ietf-lisp-deployment-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC7215</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7216</doc-id>
        <title>Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>R. Bellis</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>HELD</kw>
            <kw>LIS</kw>
            <kw>Discovery</kw>
            <kw>NAT</kw>
            <kw>Residential Gateway</kw>
        </keywords>
        <abstract><p>The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.</p><p> This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.</p></abstract>
        <draft>draft-ietf-geopriv-res-gw-lis-discovery-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC7216</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7217</doc-id>
        <title>A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another.  This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users.  The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).</p></abstract>
        <draft>draft-ietf-6man-stable-privacy-addresses-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7217</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7218</doc-id>
        <title>Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)</title>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>DANE</kw>
            <kw>Applications</kw>
        </keywords>
        <abstract><p>Experience has shown that people get confused when discussing the three numeric fields of the TLSA record.  This document specifies descriptive acronyms for the three numeric fields in TLSA records.  This document updates the format of the IANA registry created by RFC 6698.</p></abstract>
        <draft>draft-ietf-dane-registry-acronyms-04</draft>
        <updates>
            <doc-id>RFC6698</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <doi>10.17487/RFC7218</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7219</doc-id>
        <title>SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>A. Garcia-Martinez</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>ingress filtering</kw>
            <kw>packet filtering</kw>
            <kw>Neighbor Discovery</kw>
        </keywords>
        <abstract><p>This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol.  The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.</p></abstract>
        <draft>draft-ietf-savi-send-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>savi</wg_acronym>
        <doi>10.17487/RFC7219</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7220</doc-id>
        <title>Description Option for the Port Control Protocol (PCP)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping.  It does this by defining a new DESCRIPTION option.</p></abstract>
        <draft>draft-ietf-pcp-description-option-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7220</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7221</doc-id>
        <title>Handling of Internet-Drafts by IETF Working Groups</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>D. Crocker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IETF</kw>
            <kw>process</kw>
            <kw>working group</kw>
            <kw>Internet-Draft</kw>
            <kw>adoption</kw>
            <kw>handling</kw>
            <kw>creation</kw>
        </keywords>
        <abstract><p>The productive output of an IETF working group is documents, as mandated by the working group's charter.  When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point.  The document that a working group adopts and then develops further is based on initial input at varying levels of maturity.  An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between.  This document discusses how a working group typically handles the formal documents that it targets for publication.</p></abstract>
        <draft>draft-crocker-id-adoption-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7221</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7222</doc-id>
        <title>Quality-of-Service Option for Proxy Mobile IPv6</title>
        <author>
            <name>M. Liebsch</name>
        </author>
        <author>
            <name>P. Seite</name>
        </author>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
            <kw>PMIP-QoS</kw>
            <kw>PMIPv6-QoS</kw>
            <kw>WiFi-QoS</kw>
            <kw>3GPP-QoS</kw>
        </keywords>
        <abstract><p>This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6.  This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows.  The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway.  Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.</p></abstract>
        <draft>draft-ietf-netext-pmip6-qos-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7222</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7223</doc-id>
        <title>A YANG Data Model for Interface Management</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>ietf-interfaces</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for the management of network interfaces.  It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.  The data model includes configuration data and state data (status information and counters for the collection of statistics).</p></abstract>
        <draft>draft-ietf-netmod-interfaces-cfg-16</draft>
        <obsoleted-by>
            <doc-id>RFC8343</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7223</errata-url>
        <doi>10.17487/RFC7223</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7224</doc-id>
        <title>IANA Interface Type YANG Module</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>yang</kw>
            <kw>netconf</kw>
            <kw>iana-if-type</kw>
        </keywords>
        <abstract><p>This document defines the initial version of the iana-if-type YANG module.</p></abstract>
        <draft>draft-ietf-netmod-iana-if-type-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC7224</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7225</doc-id>
        <title>Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses.  This option is needed for successful communications when IPv4 addresses are used in referrals.</p></abstract>
        <draft>draft-ietf-pcp-nat64-prefix64-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7225</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7226</doc-id>
        <title>Requirements for Advanced Multipath in MPLS Networks</title>
        <author>
            <name>C. Villamizar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. McDysan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Ning</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Advanced Multipath</kw>
            <kw>composite link</kw>
            <kw>link aggregation</kw>
            <kw>ECMP</kw>
            <kw>link bundling</kw>
            <kw>delay metric</kw>
        </keywords>
        <abstract><p>This document provides a set of requirements for Advanced Multipath in MPLS networks.</p><p> Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.</p></abstract>
        <draft>draft-ietf-rtgwg-cl-requirement-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC7226</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7227</doc-id>
        <title>Guidelines for Creating New DHCPv6 Options</title>
        <author>
            <name>D. Hankins</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>M. Siodelski</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>option guidelines</kw>
            <kw>option guidance</kw>
            <kw>option format</kw>
        </keywords>
        <abstract><p>This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software.  It also provides guidelines for expert reviewers to evaluate new registrations.  This document updates RFC 3315.</p></abstract>
        <draft>draft-ietf-dhc-option-guidelines-17</draft>
        <updates>
            <doc-id>RFC3315</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0187</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7227</errata-url>
        <doi>10.17487/RFC7227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7228</doc-id>
        <title>Terminology for Constrained-Node Networks</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>M. Ersue</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>Embedded Internet</kw>
            <kw>Smart Object</kw>
            <kw>Sensor Network</kw>
            <kw>WSN</kw>
            <kw>Constrained node</kw>
            <kw>Constrained network</kw>
            <kw>LLN</kw>
            <kw>LoWPAN</kw>
            <kw>6LoWPAN</kw>
            <kw>Always-on</kw>
            <kw>Low-power</kw>
            <kw>Energy efficient</kw>
        </keywords>
        <abstract><p>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</p></abstract>
        <draft>draft-ietf-lwig-terminology-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC7228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7229</doc-id>
        <title>Object Identifiers for Test Certificate Policies</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document provides several certificate policy identifiers for testing certificate handling software.</p></abstract>
        <draft>draft-housley-pkix-test-oids-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7229</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7230</doc-id>
        <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>89</page-count>
        <keywords>
            <kw>Hyptertext Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>HTTP message format</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</p></abstract>
        <draft>draft-ietf-httpbis-p1-messaging-26</draft>
        <obsoletes>
            <doc-id>RFC2145</doc-id>
            <doc-id>RFC2616</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
            <doc-id>RFC9112</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2817</doc-id>
            <doc-id>RFC2818</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8615</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7230</errata-url>
        <doi>10.17487/RFC7230</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7231</doc-id>
        <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>HTTP semantics</kw>
            <kw>HTTP payload</kw>
            <kw>HTTP content</kw>
            <kw>HTTP method</kw>
            <kw>HTTP status code</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</p></abstract>
        <draft>draft-ietf-httpbis-p2-semantics-26</draft>
        <obsoletes>
            <doc-id>RFC2616</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2817</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7231</errata-url>
        <doi>10.17487/RFC7231</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7232</doc-id>
        <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>HyperText Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>HTTP conditional requests</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.</p></abstract>
        <draft>draft-ietf-httpbis-p4-conditional-26</draft>
        <obsoletes>
            <doc-id>RFC2616</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7232</errata-url>
        <doi>10.17487/RFC7232</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7233</doc-id>
        <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lafon</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems.  This document defines range requests and the rules for constructing and combining responses to those requests.</p></abstract>
        <draft>draft-ietf-httpbis-p5-range-26</draft>
        <obsoletes>
            <doc-id>RFC2616</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7233</errata-url>
        <doi>10.17487/RFC7233</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7234</doc-id>
        <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>HTTP caching</kw>
            <kw>HyperText Transfer Protocol</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</p></abstract>
        <draft>draft-ietf-httpbis-p6-cache-26</draft>
        <obsoletes>
            <doc-id>RFC2616</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9111</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7234</errata-url>
        <doi>10.17487/RFC7234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7235</doc-id>
        <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>HTTP authentication</kw>
            <kw>HyperText Transfer Protocol</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems.  This document defines the HTTP Authentication framework.</p></abstract>
        <draft>draft-ietf-httpbis-p7-auth-26</draft>
        <obsoletes>
            <doc-id>RFC2616</doc-id>
            <doc-id>RFC2617</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7235</errata-url>
        <doi>10.17487/RFC7235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7236</doc-id>
        <title>Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>HyperText Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>Authentication</kw>
            <kw>Authentication Scheme</kw>
        </keywords>
        <abstract><p>This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.</p></abstract>
        <draft>draft-ietf-httpbis-authscheme-registrations-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC7236</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7237</doc-id>
        <title>Initial Hypertext Transfer Protocol (HTTP) Method Registrations</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>HyperText Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>Request Method</kw>
        </keywords>
        <abstract><p>This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.</p></abstract>
        <draft>draft-ietf-httpbis-method-registrations-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC7237</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7238</doc-id>
        <title>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>redirect</kw>
            <kw>status code</kw>
        </keywords>
        <abstract><p>This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).</p></abstract>
        <draft>draft-reschke-http-status-308-07</draft>
        <obsoleted-by>
            <doc-id>RFC7538</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7238</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7239</doc-id>
        <title>Forwarded HTTP Extension</title>
        <author>
            <name>A. Petersson</name>
        </author>
        <author>
            <name>M. Nilsson</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>proxy</kw>
            <kw>x-forwarded-for</kw>
            <kw>x-forwarded-by</kw>
            <kw>x-forwarded-host</kw>
            <kw>x-forwarded-proto</kw>
            <kw>via</kw>
        </keywords>
        <abstract><p>This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.</p><p> This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.</p></abstract>
        <draft>draft-ietf-appsawg-http-forwarded-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7239</errata-url>
        <doi>10.17487/RFC7239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7240</doc-id>
        <title>Prefer Header for HTTP</title>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>http</kw>
            <kw>prefer</kw>
        </keywords>
        <abstract><p>This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.</p></abstract>
        <draft>draft-snell-http-prefer-18</draft>
        <updated-by>
            <doc-id>RFC8144</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7240</errata-url>
        <doi>10.17487/RFC7240</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7241</doc-id>
        <title>The IEEE 802/IETF Relationship</title>
        <author>
            <name>S. Dawkins</name>
        </author>
        <author>
            <name>P. Thaler</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>snmp</kw>
            <kw>aaa</kw>
            <kw>simple network management protocol</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract><p>This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.</p><p> Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.</p></abstract>
        <draft>draft-iab-rfc4441rev-08</draft>
        <obsoletes>
            <doc-id>RFC4441</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9141</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7241</errata-url>
        <doi>10.17487/RFC7241</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7242</doc-id>
        <title>Delay-Tolerant Networking TCP Convergence-Layer Protocol</title>
        <author>
            <name>M. Demmer</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>S. Perreault</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN).  It is the product of the IRTF's DTN Research Group (DTNRG).</p></abstract>
        <draft>draft-irtf-dtnrg-tcp-clayer-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7242</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7243</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric</title>
        <author>
            <name>V. Singh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>I. Curcio</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>rtp</kw>
            <kw>reception statistics</kw>
            <kw>de-jitter buffer</kw>
        </keywords>
        <abstract><p>The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics.  The available reporting may include aggregate information across longer periods of time as well as individual packet reporting.  This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7243</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7244</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting</title>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-synchronization-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7245</doc-id>
        <title>An Architecture for Media Recording Using the Session Initiation Protocol</title>
        <author>
            <name>A. Hutton</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Portman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Jain</name>
        </author>
        <author>
            <name>K. Rehor</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>sip</kw>
        </keywords>
        <abstract><p>Session recording is a critical requirement in many communications environments such as call centers and financial trading.  In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.  Recording of a session is typically performed by sending a copy of a media stream to a recording device.  This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).</p></abstract>
        <draft>draft-ietf-siprec-architecture-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>siprec</wg_acronym>
        <doi>10.17487/RFC7245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7246</doc-id>
        <title>Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Hitchen</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>A. Gulko</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network.  Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region.  In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region.  Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region.  This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification.  However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.</p></abstract>
        <draft>draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03</draft>
        <updated-by>
            <doc-id>RFC7438</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC7246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7247</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>A. Houri</name>
        </author>
        <author>
            <name>J. Hildebrand</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.</p></abstract>
        <draft>draft-ietf-stox-core-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>stox</wg_acronym>
        <doi>10.17487/RFC7247</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7248</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>A. Houri</name>
        </author>
        <author>
            <name>J. Hildebrand</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>SIP</kw>
            <kw>SIMPLE</kw>
            <kw>IM</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
        </keywords>
        <abstract><p>This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).</p></abstract>
        <draft>draft-ietf-stox-presence-09</draft>
        <obsoleted-by>
            <doc-id>RFC8048</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>stox</wg_acronym>
        <doi>10.17487/RFC7248</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7249</doc-id>
        <title>Internet Numbers Registries</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.</p><p> This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.</p></abstract>
        <draft>draft-housley-number-registries-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7249</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7250</doc-id>
        <title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>P. Wouters</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Gilmore</name>
        </author>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>DNSSEC</kw>
            <kw>DANE</kw>
            <kw>Raw Public Key</kw>
        </keywords>
        <abstract><p>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</p></abstract>
        <draft>draft-ietf-tls-oob-pubkey-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7250</errata-url>
        <doi>10.17487/RFC7250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7251</doc-id>
        <title>AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>D. Bailey</name>
        </author>
        <author>
            <name>M. Campagna</name>
        </author>
        <author>
            <name>R. Dugal</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication.  The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security.  The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.</p></abstract>
        <draft>draft-mcgrew-tls-aes-ccm-ecc-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7252</doc-id>
        <title>The Constrained Application Protocol (CoAP)</title>
        <author>
            <name>Z. Shelby</name>
        </author>
        <author>
            <name>K. Hartke</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>112</page-count>
        <abstract><p>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</p><p> CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</p></abstract>
        <draft>draft-ietf-core-coap-18</draft>
        <updated-by>
            <doc-id>RFC7959</doc-id>
            <doc-id>RFC8613</doc-id>
            <doc-id>RFC8974</doc-id>
            <doc-id>RFC9175</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7252</errata-url>
        <doi>10.17487/RFC7252</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7253</doc-id>
        <title>The OCB Authenticated-Encryption Algorithm</title>
        <author>
            <name>T. Krovetz</name>
        </author>
        <author>
            <name>P. Rogaway</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>OCB</kw>
            <kw>AEAD</kw>
            <kw>authenticated-encryption</kw>
        </keywords>
        <abstract><p>This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data.  This document is a product of the Crypto Forum Research Group (CFRG).</p></abstract>
        <draft>draft-irtf-cfrg-ocb-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7253</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7254</doc-id>
        <title>A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)</title>
        <author>
            <name>M. Montemurro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Allen</name>
        </author>
        <author>
            <name>D. McDonald</name>
        </author>
        <author>
            <name>P. Gosden</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>GSM</kw>
            <kw>UMTS</kw>
            <kw>LTE</kw>
            <kw>3GPP</kw>
            <kw>Mobile</kw>
            <kw>identifier</kw>
            <kw>instance ID</kw>
        </keywords>
        <abstract><p>This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV).  The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks.  The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA.  URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.</p></abstract>
        <draft>draft-montemurro-gsma-imei-urn-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7254</errata-url>
        <doi>10.17487/RFC7254</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7255</doc-id>
        <title>Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID</title>
        <author>
            <name>A. Allen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>GSM</kw>
            <kw>UMTS</kw>
            <kw>LTE</kw>
            <kw>3GPP</kw>
            <kw>IMS</kw>
            <kw>SIP</kw>
            <kw>GRUU</kw>
            <kw>Mobile</kw>
            <kw>identifier</kw>
            <kw>instance ID</kw>
        </keywords>
        <abstract><p>This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id.  Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.</p></abstract>
        <draft>draft-allen-dispatch-imei-urn-as-instanceid-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7256</doc-id>
        <title>Multicast Control Extensions for the Access Node Control Protocol (ANCP)</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>R. Maglione</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>99</page-count>
        <abstract><p>This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:</p><p> o multicast replication initiated by the Network Access Server (NAS);</p><p> o conditional access and admission control with white and black lists;</p><p> o conditional access and admission control with grey lists;</p><p> o bandwidth delegation; and</p><p> o committed bandwidth reporting.</p><p> These capabilities may be combined according to the rules given in this specification.</p><p> This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.</p></abstract>
        <draft>draft-ietf-ancp-mc-extensions-16</draft>
        <updates>
            <doc-id>RFC6320</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ancp</wg_acronym>
        <doi>10.17487/RFC7256</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7257</doc-id>
        <title>Virtual Private LAN Service (VPLS) Management Information Base</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Kiran Koushik</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Mediratta</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <abstract><p>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 to configure and/or monitor Virtual Private LAN services.  It needs to be used in conjunction with the Pseudowire (PW) Management Information Base (PW-STD-MIB from RFC 5601).</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-mib-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7257</errata-url>
        <doi>10.17487/RFC7257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7258</doc-id>
        <title>Pervasive Monitoring Is an Attack</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>pervasive monitoring</kw>
        </keywords>
        <abstract><p>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</p></abstract>
        <draft>draft-farrell-perpass-attack-06</draft>
        <is-also>
            <doc-id>BCP0188</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7258</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7259</doc-id>
        <title>The Jabber-ID Header Field</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Jabber</kw>
            <kw>XMPP</kw>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>email</kw>
            <kw>netnews</kw>
            <kw>message header field</kw>
            <kw>IM</kw>
            <kw>instant messaging</kw>
        </keywords>
        <abstract><p>This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.</p></abstract>
        <draft>draft-saintandre-jabberid-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7259</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7260</doc-id>
        <title>GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration</title>
        <author>
            <name>A. Takacs</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>J. He</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>MPLS-TP</kw>
            <kw>Transport Profile</kw>
            <kw>GELS</kw>
            <kw>Ethernet Label Switching</kw>
            <kw>PBB-TE</kw>
            <kw>connectivity monitoring</kw>
            <kw>OAM configuration</kw>
        </keywords>
        <abstract><p>Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation.  In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities.  This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.</p></abstract>
        <draft>draft-ietf-ccamp-oam-configuration-fwk-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7260</errata-url>
        <doi>10.17487/RFC7260</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7261</doc-id>
        <title>Offer/Answer Considerations for G723 Annex A and G729 Annex B</title>
        <author>
            <name>M. Perumal</name>
        </author>
        <author>
            <name>P. Ravindran</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>offer</kw>
            <kw>answer</kw>
        </keywords>
        <abstract><p>This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.</p></abstract>
        <draft>draft-ietf-mmusic-sdp-g723-g729-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7261</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7262</doc-id>
        <title>Requirements for Telepresence Multistreams</title>
        <author>
            <name>A. Romanow</name>
        </author>
        <author>
            <name>S. Botzko</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE).  In addition, the problem statement and related definitions are also covered herein.</p></abstract>
        <draft>draft-ietf-clue-telepresence-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC7262</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7263</doc-id>
        <title>An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing</title>
        <author>
            <name>N. Zong</name>
        </author>
        <author>
            <name>X. Jiang</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>Y. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response routing mode.  RELOAD recommends symmetric recursive routing for routing messages.  The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers.  This document also describes potential cases where this extension can be used.</p></abstract>
        <draft>draft-ietf-p2psip-drr-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7263</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7264</doc-id>
        <title>An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing</title>
        <author>
            <name>N. Zong</name>
        </author>
        <author>
            <name>X. Jiang</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>Y. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode.  RELOAD recommends symmetric recursive routing for routing messages.  The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers.  This document also describes potential cases where this extension can be used.</p></abstract>
        <draft>draft-ietf-p2psip-rpr-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7265</doc-id>
        <title>jCal: The JSON Format for iCalendar</title>
        <author>
            <name>P. Kewisch</name>
        </author>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>M. Douglass</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>This specification defines "jCal", a JSON format for iCalendar data.  The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events.  JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.</p></abstract>
        <draft>draft-ietf-jcardcal-jcal-10</draft>
        <updated-by>
            <doc-id>RFC7529</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>jcardcal</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7265</errata-url>
        <doi>10.17487/RFC7265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7266</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>R. Schott</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-qoe-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7267</doc-id>
        <title>Dynamic Placement of Multi-Segment Pseudowires</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Bocci</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Balus</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>pw</kw>
            <kw>pw switching point pe sub-tlv</kw>
        </keywords>
        <abstract><p>RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains.  A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW.  This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers.  This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.</p></abstract>
        <draft>draft-ietf-pwe3-dynamic-ms-pw-22</draft>
        <updates>
            <doc-id>RFC6073</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7268</doc-id>
        <title>RADIUS Attributes for IEEE 802 Networks</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Malinen</name>
        </author>
        <author>
            <name>P. Congdon</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs).  This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute.  This document updates RFCs 3580 and 4072.</p></abstract>
        <draft>draft-ietf-radext-ieee802ext-12</draft>
        <updates>
            <doc-id>RFC3580</doc-id>
            <doc-id>RFC4072</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8044</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC7268</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7269</doc-id>
        <title>NAT64 Deployment Options and Experience</title>
        <author>
            <name>G. Chen</name>
        </author>
        <author>
            <name>Z. Cao</name>
        </author>
        <author>
            <name>C. Xie</name>
        </author>
        <author>
            <name>D. Binet</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document summarizes NAT64 function deployment scenarios and operational experience.  Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.</p></abstract>
        <draft>draft-ietf-v6ops-nat64-experience-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7270</doc-id>
        <title>Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)</title>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IPFIX</kw>
        </keywords>
        <abstract><p>This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.</p></abstract>
        <draft>draft-yourtchenko-cisco-ies-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7270</errata-url>
        <doi>10.17487/RFC7270</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7271</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators</title>
        <author>
            <name>J. Ryoo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Gray</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <author>
            <name>T. Cheung</name>
        </author>
        <author>
            <name>E. Osborne</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>PSC mode</kw>
            <kw>APS mode</kw>
            <kw>capabilities</kw>
            <kw>priority</kw>
            <kw>non-revertive</kw>
            <kw>MS-W support</kw>
            <kw>SD support</kw>
            <kw>EXER support</kw>
        </keywords>
        <abstract><p>This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.</p><p> This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.</p><p> This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.</p><p> This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.</p></abstract>
        <draft>draft-ietf-mpls-tp-psc-itu-04</draft>
        <updates>
            <doc-id>RFC6378</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8234</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7271</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7272</doc-id>
        <title>Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)</title>
        <author>
            <name>R. van Brandenburg</name>
        </author>
        <author>
            <name>H. Stokking</name>
        </author>
        <author>
            <name>O. van Deventer</name>
        </author>
        <author>
            <name>F. Boronat</name>
        </author>
        <author>
            <name>M. Montagud</name>
        </author>
        <author>
            <name>K. Gross</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Inter-Destination Media Synchronization</kw>
            <kw>RTP Control Protocol</kw>
            <kw>RTCP</kw>
        </keywords>
        <abstract><p>This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.</p><p> Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.</p></abstract>
        <draft>draft-ietf-avtcore-idms-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7272</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7273</doc-id>
        <title>RTP Clock Source Signalling</title>
        <author>
            <name>A. Williams</name>
        </author>
        <author>
            <name>K. Gross</name>
        </author>
        <author>
            <name>R. van Brandenburg</name>
        </author>
        <author>
            <name>H. Stokking</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>clock</kw>
            <kw>source</kw>
        </keywords>
        <abstract><p>NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements.  This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.</p></abstract>
        <draft>draft-ietf-avtcore-clksrc-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7273</errata-url>
        <doi>10.17487/RFC7273</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7274</doc-id>
        <title>Allocating and Retiring Special-Purpose MPLS Labels</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.</p><p> As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.</p><p> This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.</p><p> This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.</p></abstract>
        <draft>draft-ietf-mpls-special-purpose-labels-06</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
            <doc-id>RFC3038</doc-id>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC3811</doc-id>
            <doc-id>RFC4182</doc-id>
            <doc-id>RFC4928</doc-id>
            <doc-id>RFC5331</doc-id>
            <doc-id>RFC5586</doc-id>
            <doc-id>RFC5921</doc-id>
            <doc-id>RFC5960</doc-id>
            <doc-id>RFC6391</doc-id>
            <doc-id>RFC6478</doc-id>
            <doc-id>RFC6790</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9017</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7274</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7275</doc-id>
        <title>Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>iccp</kw>
        </keywords>
        <abstract><p>This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications.  The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems.  It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.</p></abstract>
        <draft>draft-ietf-pwe3-iccp-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7275</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7276</doc-id>
        <title>An Overview of Operations, Administration, and Maintenance (OAM) Tools</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>N. Sprecher</name>
        </author>
        <author>
            <name>E. Bellagamba</name>
        </author>
        <author>
            <name>Y. Weingarten</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.</p><p> This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.</p><p> The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.</p></abstract>
        <draft>draft-ietf-opsawg-oam-overview-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7276</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7277</doc-id>
        <title>A YANG Data Model for IP Management</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>netmod</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for management of IP implementations.  The data model includes configuration data and state data.</p></abstract>
        <draft>draft-ietf-netmod-ip-cfg-14</draft>
        <obsoleted-by>
            <doc-id>RFC8344</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC7277</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7278</doc-id>
        <title>Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link</title>
        <author>
            <name>C. Byrne</name>
        </author>
        <author>
            <name>D. Drown</name>
        </author>
        <author>
            <name>A. Vizdal</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.</p></abstract>
        <draft>draft-ietf-v6ops-64share-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7278</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7279</doc-id>
        <title>An Acceptable Use Policy for New ICMP Types and Codes</title>
        <author>
            <name>M. Shore</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>May</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>icmp</kw>
            <kw>icmpv4</kw>
            <kw>icmpv6</kw>
        </keywords>
        <abstract><p>In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.</p><p> This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.</p></abstract>
        <draft>draft-shore-icmp-aup-12</draft>
        <is-also>
            <doc-id>BCP0189</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7279</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7280</doc-id>
        <title>IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>ULE</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next- Header registry.  This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.</p></abstract>
        <draft>draft-fairhurst-ipdvb-ule-iana-07</draft>
        <updates>
            <doc-id>RFC4326</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7280</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7281</doc-id>
        <title>Authentication-Results Registration for S/MIME Signature Verification</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Authentication-Results</kw>
            <kw>S/MIME</kw>
        </keywords>
        <abstract><p>RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks.  This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks.</p></abstract>
        <draft>draft-melnikov-authentication-results-smime-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7281</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7282</doc-id>
        <title>On Consensus and Humming in the IETF</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>accommodate</kw>
            <kw>agree</kw>
            <kw>agreement</kw>
            <kw>appease</kw>
            <kw>argue</kw>
            <kw>argument</kw>
            <kw>balloting</kw>
            <kw>capitulated</kw>
            <kw>capitulation</kw>
            <kw>chair</kw>
            <kw>choice</kw>
            <kw>choose</kw>
            <kw>coin</kw>
            <kw>compromise</kw>
            <kw>count</kw>
            <kw>decide</kw>
            <kw>decision</kw>
            <kw>disagree</kw>
            <kw>disagreement</kw>
            <kw>hands</kw>
            <kw>horse-trade</kw>
            <kw>horse-trading</kw>
            <kw>hum</kw>
            <kw>issue</kw>
            <kw>judge</kw>
            <kw>judging</kw>
            <kw>king</kw>
            <kw>majority</kw>
            <kw>member</kw>
            <kw>minority</kw>
            <kw>object</kw>
            <kw>objection</kw>
            <kw>objector</kw>
            <kw>president</kw>
            <kw>rough</kw>
            <kw>unaddressed</kw>
            <kw>vote</kw>
            <kw>voting</kw>
            <kw>working group</kw>
        </keywords>
        <abstract><p>The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.</p><p> Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.</p></abstract>
        <draft>draft-resnick-on-consensus-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7282</errata-url>
        <doi>10.17487/RFC7282</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7283</doc-id>
        <title>Handling Unknown DHCPv6 Messages</title>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Unknown Messages</kw>
        </keywords>
        <abstract><p>DHCPv6 is not specific about handling messages with unknown types.  This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages.  This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents.  This document updates RFC 3315.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-unknown-msg-08</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3315</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7283</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7284</doc-id>
        <title>The Profile URI Registry</title>
        <author>
            <name>M. Lanthaler</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>profile</kw>
            <kw>profiles</kw>
            <kw>URI</kw>
            <kw>registry</kw>
        </keywords>
        <abstract><p>This document defines a registry for profile URIs to be used in specifications standardizing profiles.</p></abstract>
        <draft>draft-lanthaler-profile-registry-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7284</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7285</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
        <author>
            <name>R. Alimi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Penno</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Yang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Kiesel</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>W. Roome</name>
        </author>
        <author>
            <name>S. Shalunov</name>
        </author>
        <author>
            <name>R. Woundy</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>91</page-count>
        <keywords>
            <kw>ALTO Information Resources</kw>
            <kw>Network Map</kw>
            <kw>PID</kw>
            <kw>Filtered Network Map</kw>
            <kw>Cost Map</kw>
            <kw>Endpoint Property Service</kw>
            <kw>Endpoint Cost Service</kw>
        </keywords>
        <abstract><p>Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.</p><p> The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.</p><p> This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.</p></abstract>
        <draft>draft-ietf-alto-protocol-27</draft>
        <updated-by>
            <doc-id>RFC9274</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7285</errata-url>
        <doi>10.17487/RFC7285</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7286</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Server Discovery</title>
        <author>
            <name>S. Kiesel</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>N. Schwan</name>
        </author>
        <author>
            <name>M. Scharf</name>
        </author>
        <author>
            <name>H. Song</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.</p><p> This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.</p></abstract>
        <draft>draft-ietf-alto-server-discovery-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC7286</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7287</doc-id>
        <title>Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains</title>
        <author>
            <name>T. Schmidt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gao</name>
        </author>
        <author>
            <name>H. Zhang</name>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes.  This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios.  Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined.  Mobile sources always remain agnostic of multicast mobility operations.</p></abstract>
        <draft>draft-ietf-multimob-pmipv6-source-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>multimob</wg_acronym>
        <doi>10.17487/RFC7287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7288</doc-id>
        <title>Reflections on Host Firewalls</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Filter</kw>
            <kw>Filtering</kw>
        </keywords>
        <abstract><p>In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice.  Unlike traditional firewalls that protect network links, host firewalls run in end-user systems.  Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall.  It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication.  In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.</p></abstract>
        <draft>draft-iab-host-firewalls-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7288</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7289</doc-id>
        <title>Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs</title>
        <author>
            <name>V. Kuarsingh</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Cianfarani</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>NAT444</kw>
            <kw>LSN</kw>
            <kw>Large-Scale NAT</kw>
        </keywords>
        <abstract><p>This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT).  The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function.  Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN.  Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone.  This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings.  The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network.  This document does not intend to defend the merits of CGN.</p></abstract>
        <draft>draft-ietf-opsawg-lsn-deployment-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7289</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7290</doc-id>
        <title>Test Plan and Results for Advancing RFC 2680 on the Standards Track</title>
        <author>
            <name>L. Ciavattone</name>
        </author>
        <author>
            <name>R. Geib</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>M. Wieser</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>packet loss</kw>
            <kw>IPPM implementation comparison</kw>
            <kw>perfas+</kw>
            <kw>netem</kw>
            <kw>IPPM comparison</kw>
            <kw>metric test, WIPM</kw>
            <kw>NetProbe</kw>
        </keywords>
        <abstract><p>This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track.  Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended.  Two completely independent implementations have been tested against the key specifications of RFC 2680.</p></abstract>
        <draft>draft-ietf-ippm-testplan-rfc2680-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7290</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7291</doc-id>
        <title>DHCP Options for the Port Control Protocol (PCP)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PCP Server discovery</kw>
            <kw>Port Mapping</kw>
            <kw>Shared Address</kw>
        </keywords>
        <abstract><p>This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses.  The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios.  The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.</p></abstract>
        <draft>draft-ietf-pcp-dhcp-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7291</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7292</doc-id>
        <title>PKCS #12: Personal Information Exchange Syntax v1.1</title>
        <author>
            <name>K. Moriarty</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <author>
            <name>S. Parkinson</name>
        </author>
        <author>
            <name>A. Rusch</name>
        </author>
        <author>
            <name>M. Scott</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>PKCS#12</kw>
            <kw>PKCS12v1.1</kw>
            <kw>PKCS#12v1.1</kw>
        </keywords>
        <abstract><p>PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.</p><p> This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</p></abstract>
        <draft>draft-moriarty-pkcs12v1-1-05</draft>
        <updated-by>
            <doc-id>RFC9579</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7292</errata-url>
        <doi>10.17487/RFC7292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7293</doc-id>
        <title>The Require-Recipient-Valid-Since Header Field and SMTP Service Extension</title>
        <author>
            <name>W. Mills</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Privacy</kw>
            <kw>Email</kw>
            <kw>Account Expiration</kw>
        </keywords>
        <abstract><p>This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.</p><p> The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.</p></abstract>
        <draft>draft-ietf-appsawg-rrvs-header-field-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7293</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7294</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications</title>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>C. Bi</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Real Time Control Protocol</kw>
        </keywords>
        <abstract><p>This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-loss-conceal-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7294</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7295</doc-id>
        <title>Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>Z. Sarker</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Congestion Control</kw>
            <kw>RTCWEB</kw>
            <kw>Workshop</kw>
            <kw>Real-Time Communication</kw>
        </keywords>
        <abstract><p>This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.</p><p> The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).</p></abstract>
        <draft>draft-iab-cc-workshop-report-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7295</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7296</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>C. Kaufman</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>142</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IPsec</kw>
        </keywords>
        <abstract><p>This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document obsoletes RFC 5996, and includes all of the errata for it.  It advances IKEv2 to be an Internet Standard.</p></abstract>
        <draft>draft-kivinen-ipsecme-ikev2-rfc5996bis-04</draft>
        <obsoletes>
            <doc-id>RFC5996</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7427</doc-id>
            <doc-id>RFC7670</doc-id>
            <doc-id>RFC8247</doc-id>
            <doc-id>RFC8983</doc-id>
            <doc-id>RFC9370</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0079</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7296</errata-url>
        <doi>10.17487/RFC7296</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7297</doc-id>
        <title>IP Connectivity Provisioning Profile (CPP)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>N. Wang</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.</p><p> Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.</p></abstract>
        <draft>draft-boucadair-connectivity-provisioning-profile-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7298</doc-id>
        <title>Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication</title>
        <author>
            <name>D. Ovsienko</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>routing protocol</kw>
            <kw>authentication</kw>
            <kw>applied cryptography</kw>
        </keywords>
        <abstract><p>This document describes a cryptographic authentication mechanism for the Babel routing protocol.  This document updates RFC 6126.  The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.</p></abstract>
        <draft>draft-ovsienko-babel-hmac-authentication-09</draft>
        <obsoleted-by>
            <doc-id>RFC8967</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6126</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7298</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7299</doc-id>
        <title>Object Identifier Registry for the PKIX Working Group</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Public-Key Infrastructure using X.509</kw>
        </keywords>
        <abstract><p>When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group.  This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.</p></abstract>
        <draft>draft-housley-pkix-oids-03</draft>
        <updated-by>
            <doc-id>RFC9158</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7299</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7300</doc-id>
        <title>Reservation of Last Autonomous System (AS) Numbers</title>
        <author>
            <name>J. Haas</name>
        </author>
        <author>
            <name>J. Mitchell</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>asn</kw>
            <kw>last asns</kw>
        </keywords>
        <abstract><p>This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as "Last ASNs", and provides guidance to implementers and operators on their use.  This document updates Section 10 of RFC 1930.</p></abstract>
        <draft>draft-ietf-idr-last-as-reservation-07</draft>
        <updates>
            <doc-id>RFC1930</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0006</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7300</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7301</doc-id>
        <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
        <author>
            <name>S. Friedl</name>
        </author>
        <author>
            <name>A. Popov</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>E. Stephan</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ALPN</kw>
        </keywords>
        <abstract><p>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake.  For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</p></abstract>
        <draft>draft-ietf-tls-applayerprotoneg-05</draft>
        <updated-by>
            <doc-id>RFC8447</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7301</errata-url>
        <doi>10.17487/RFC7301</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7302</doc-id>
        <title>Entertainment Identifier Registry (EIDR) URN Namespace Definition</title>
        <author>
            <name>P. Lemieux</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>EIDR</kw>
            <kw>Entertainment Identifier Registry</kw>
            <kw>URN</kw>
        </keywords>
        <abstract><p>Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content.  This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.</p></abstract>
        <draft>draft-pal-eidr-urn-03</draft>
        <obsoleted-by>
            <doc-id>RFC7972</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7302</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7303</doc-id>
        <title>XML Media Types</title>
        <author>
            <name>H. Thompson</name>
        </author>
        <author>
            <name>C. Lilley</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>application/xml</kw>
            <kw>application/xml-external-parsed-entity</kw>
            <kw>application/xml-dtd</kw>
            <kw>text/xml</kw>
            <kw>text/xml-external-parsed-entity</kw>
            <kw>+xml</kw>
        </keywords>
        <abstract><p>This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types.  This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.</p></abstract>
        <draft>draft-ietf-appsawg-xml-mediatypes-10</draft>
        <obsoletes>
            <doc-id>RFC3023</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC6839</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7303</errata-url>
        <doi>10.17487/RFC7303</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7304</doc-id>
        <title>A Method for Mitigating Namespace Collisions</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.</p></abstract>
        <draft>draft-wkumari-dnsop-defense-collision-mitigate-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7305</doc-id>
        <title>Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)</title>
        <author>
            <name>E. Lear</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-itat-report-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7305</errata-url>
        <doi>10.17487/RFC7305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7306</doc-id>
        <title>Remote Direct Memory Access (RDMA) Protocol Extensions</title>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>F. Marti</name>
        </author>
        <author>
            <name>W. Noureddine</name>
        </author>
        <author>
            <name>A. Eiriksson</name>
        </author>
        <author>
            <name>R. Sharp</name>
        </author>
        <date>
            <month>June</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>iWARP</kw>
            <kw>RDMAP</kw>
            <kw>DDP</kw>
            <kw>RDMA</kw>
            <kw>DMA</kw>
        </keywords>
        <abstract><p>This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040.  RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies.  The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data.</p></abstract>
        <draft>draft-ietf-storm-rdmap-ext-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>storm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7306</errata-url>
        <doi>10.17487/RFC7306</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7307</doc-id>
        <title>LDP Extensions for Multi-Topology</title>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <author>
            <name>L. Li</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MT</kw>
            <kw>Label Distribution Protocol</kw>
        </keywords>
        <abstract><p>Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.</p><p> This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.</p></abstract>
        <draft>draft-ietf-mpls-ldp-multi-topology-12</draft>
        <updated-by>
            <doc-id>RFC9658</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7307</errata-url>
        <doi>10.17487/RFC7307</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7308</doc-id>
        <title>Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)</title>
        <author>
            <name>E. Osborne</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>colors</kw>
            <kw>link colors</kw>
            <kw>igp te extensions</kw>
        </keywords>
        <abstract><p>MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).</p><p> This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.</p></abstract>
        <draft>draft-ietf-mpls-extended-admin-group-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7308</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7309</doc-id>
        <title>Redundancy Mechanism for Inter-domain VPLS Service</title>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>L. Jin</name>
        </author>
        <author>
            <name>R. Chen</name>
        </author>
        <author>
            <name>D. Cai</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ICCP</kw>
            <kw>PW</kw>
        </keywords>
        <abstract><p>In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain.  This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy.  This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-inter-domain-redundancy-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC7309</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7310</doc-id>
        <title>RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs</title>
        <author>
            <name>J. Lindsay</name>
        </author>
        <author>
            <name>H. Foerster</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets.  The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).</p></abstract>
        <draft>draft-ietf-payload-rtp-aptx-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC7310</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7311</doc-id>
        <title>The Accumulated IGP Metric Attribute for BGP</title>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>R. Fernando</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized.  BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric.  It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter-administration coordination problems.  However, there are deployments in which a single administration runs several contiguous BGP networks.  In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do.  The purpose of this document is to provide a specification for doing so.</p></abstract>
        <draft>draft-ietf-idr-aigp-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7311</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7312</doc-id>
        <title>Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)</title>
        <author>
            <name>J. Fabini</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Measurement</kw>
            <kw>Wireless</kw>
            <kw>Reactive</kw>
            <kw>Repeatability</kw>
            <kw>Continuity</kw>
            <kw>Actionable</kw>
            <kw>Conservative</kw>
            <kw>Spatial Composition</kw>
            <kw>Temporal Composition</kw>
        </keywords>
        <abstract><p>To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets.  This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing.  The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows.  Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance.  This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.</p></abstract>
        <draft>draft-ietf-ippm-2330-update-05</draft>
        <updates>
            <doc-id>RFC2330</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7312</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7313</doc-id>
        <title>Enhanced Route Refresh Capability for BGP-4</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>B. Venkatachalapathy</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Border Gateway Protocol</kw>
            <kw>bgp rib</kw>
            <kw>BGP Routing Information Base</kw>
        </keywords>
        <abstract><p>In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh.  The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner.  This document updates RFC 2918.</p></abstract>
        <draft>draft-ietf-idr-bgp-enhanced-route-refresh-10</draft>
        <updates>
            <doc-id>RFC2918</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7313</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7314</doc-id>
        <title>Extension Mechanisms for DNS (EDNS) EXPIRE Option</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IXFR</kw>
            <kw>AXFR</kw>
            <kw>zone</kw>
            <kw>transfer</kw>
            <kw>DNS</kw>
            <kw>SOA</kw>
        </keywords>
        <abstract><p>This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.</p></abstract>
        <draft>draft-andrews-dnsext-expire-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7314</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7315</doc-id>
        <title>Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP</title>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>K. Drage</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments.  The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses.  This document obsoletes RFC 3455.</p></abstract>
        <draft>draft-drage-sipping-rfc3455bis-14</draft>
        <obsoletes>
            <doc-id>RFC3455</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7913</doc-id>
            <doc-id>RFC7976</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7315</errata-url>
        <doi>10.17487/RFC7315</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7316</doc-id>
        <title>The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)</title>
        <author>
            <name>J. van Elburg</name>
        </author>
        <author>
            <name>K. Drage</name>
        </author>
        <author>
            <name>M. Ohsugi</name>
        </author>
        <author>
            <name>S. Schubert</name>
        </author>
        <author>
            <name>K. Arai</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP.  The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network.  A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.</p></abstract>
        <draft>draft-vanelburg-dispatch-private-network-ind-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7316</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7317</doc-id>
        <title>A YANG Data Model for System Management</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>NETCONF</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server.  This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.</p></abstract>
        <draft>draft-ietf-netmod-system-mgmt-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7317</errata-url>
        <doi>10.17487/RFC7317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7318</doc-id>
        <title>Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource Public Key Infrastructure (RPKI) resource certificates.</p></abstract>
        <draft>draft-ietf-sidr-policy-qualifiers-02</draft>
        <updates>
            <doc-id>RFC6487</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC7318</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7319</doc-id>
        <title>IANA Considerations for Connectivity Fault Management (CFM) Code Points</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>CFM</kw>
            <kw>OAM</kw>
            <kw>Connectivity</kw>
            <kw>Continuity</kw>
            <kw>Fault</kw>
            <kw>IANA</kw>
            <kw>TRILL</kw>
        </keywords>
        <abstract><p>IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities.  CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information.  IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF.  This document specifies the IANA considerations for the assignment of values from these blocks.</p></abstract>
        <draft>draft-eastlake-iana-cfm-considerations-02</draft>
        <is-also>
            <doc-id>BCP0191</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7319</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7320</doc-id>
        <title>URI Design and Ownership</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>URI structure</kw>
        </keywords>
        <abstract><p>Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme.  While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership.  This document further describes this problematic practice and provides some acceptable alternatives for use in standards.</p></abstract>
        <draft>draft-ietf-appsawg-uri-get-off-my-lawn-05</draft>
        <obsoleted-by>
            <doc-id>RFC8820</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3986</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7320</errata-url>
        <doi>10.17487/RFC7320</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7321</doc-id>
        <title>Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.</p><p> ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.</p></abstract>
        <draft>draft-ietf-ipsecme-esp-ah-reqts-10</draft>
        <obsoletes>
            <doc-id>RFC4835</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8221</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC7321</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7322</doc-id>
        <title>RFC Style Guide</title>
        <author>
            <name>H. Flanagan</name>
        </author>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>editorial guidance</kw>
            <kw>format</kw>
            <kw>style manual</kw>
            <kw>house style</kw>
        </keywords>
        <abstract><p>This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series.  It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC.  Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide.  This document obsoletes RFC 2223, "Instructions to RFC Authors".</p></abstract>
        <draft>draft-iab-styleguide-02</draft>
        <obsoletes>
            <doc-id>RFC2223</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7997</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7322</errata-url>
        <doi>10.17487/RFC7322</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7323</doc-id>
        <title>TCP Extensions for High Performance</title>
        <author>
            <name>D. Borman</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>R. Scheffenegger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>Timestamps</kw>
            <kw>Timestamp</kw>
            <kw>RTT</kw>
            <kw>RTTM</kw>
            <kw>Window Scale</kw>
            <kw>PAWS</kw>
            <kw>TCP options</kw>
        </keywords>
        <abstract><p>This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.</p><p> This document obsoletes RFC 1323 and describes changes from it.</p></abstract>
        <draft>draft-ietf-tcpm-1323bis-21</draft>
        <obsoletes>
            <doc-id>RFC1323</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7323</errata-url>
        <doi>10.17487/RFC7323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7324</doc-id>
        <title>Updates to MPLS Transport Profile Linear Protection</title>
        <author>
            <name>E. Osborne</name>
        </author>
        <date>
            <month>July</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>mpls-tp</kw>
            <kw>psc</kw>
            <kw>protection state coordination</kw>
        </keywords>
        <abstract><p>This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile (MPLS-TP) Linear Protection".  These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.</p></abstract>
        <draft>draft-ietf-mpls-psc-updates-06</draft>
        <updates>
            <doc-id>RFC6378</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7324</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7325</doc-id>
        <title>MPLS Forwarding Compliance and Performance Requirements</title>
        <author>
            <name>C. Villamizar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>ECMP</kw>
            <kw>link bundling</kw>
            <kw>multipath</kw>
            <kw>MPLS-TP</kw>
            <kw>forwarding</kw>
        </keywords>
        <abstract><p>This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations.  Guidelines cover many aspects of MPLS forwarding.  Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.</p></abstract>
        <draft>draft-ietf-mpls-forwarding-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7326</doc-id>
        <title>Energy Management Framework</title>
        <author>
            <name>J. Parello</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>B. Schoening</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <abstract><p>This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks.  The framework presents a physical reference model and information model.  The information model consists of an Energy Management Domain as a set of Energy Objects.  Each Energy Object can be attributed with identity, classification, and context.  Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery.  Additionally, the framework models relationships and capabilities between Energy Objects.</p></abstract>
        <draft>draft-ietf-eman-framework-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <doi>10.17487/RFC7326</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC7327</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC7328</doc-id>
        <title>Writing I-Ds and RFCs Using Pandoc and a Bit of XML</title>
        <author>
            <name>R. Gieben</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) or RFCs.</p><p> The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.</p></abstract>
        <draft>draft-gieben-pandoc2rfc-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7328</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7329</doc-id>
        <title>A Session Identifier for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.</p><p> The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.</p></abstract>
        <draft>draft-kaplan-insipid-session-id-04</draft>
        <obsoleted-by>
            <doc-id>RFC7989</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7330</doc-id>
        <title>Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>BFD</kw>
        </keywords>
        <abstract><p>This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information.  The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.</p></abstract>
        <draft>draft-ietf-bfd-tc-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC7330</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7331</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) Management Information Base</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>BFD</kw>
        </keywords>
        <abstract><p>This document 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 modeling the Bidirectional Forwarding Detection (BFD) protocol.</p></abstract>
        <draft>draft-ietf-bfd-mib-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7331</errata-url>
        <doi>10.17487/RFC7331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7332</doc-id>
        <title>Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)</title>
        <author>
            <name>H. Kaplan</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values.  This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.</p></abstract>
        <draft>draft-ietf-straw-b2bua-loop-detection-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>straw</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7332</errata-url>
        <doi>10.17487/RFC7332</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7333</doc-id>
        <title>Requirements for Distributed Mobility Management</title>
        <author>
            <name>H. Chan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Liu</name>
        </author>
        <author>
            <name>P. Seite</name>
        </author>
        <author>
            <name>H. Yokota</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Distributed Mobility Management</kw>
            <kw>Network function distribution</kw>
            <kw>Flat mobile network</kw>
            <kw>Mobile network operation and management</kw>
            <kw>Control and data plane separation</kw>
        </keywords>
        <abstract><p>This document defines the requirements for Distributed Mobility Management (DMM) at the network layer.  The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors.  As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route.  The motivation and the problems addressed by each requirement are also described.</p></abstract>
        <draft>draft-ietf-dmm-requirements-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC7333</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7334</doc-id>
        <title>PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths</title>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>R. Casellas</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Core-tree</kw>
        </keywords>
        <abstract><p>The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.</p><p> This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.</p></abstract>
        <draft>draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7334</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7335</doc-id>
        <title>IPv4 Service Continuity Prefix</title>
        <author>
            <name>C. Byrne</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element.  Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.</p></abstract>
        <draft>draft-ietf-v6ops-clatip-04</draft>
        <updates>
            <doc-id>RFC6333</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7336</doc-id>
        <title>Framework for Content Distribution Network Interconnection (CDNI)</title>
        <author>
            <name>L. Peterson</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>R. van Brandenburg</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>CDNI</kw>
            <kw>content delivery network</kw>
            <kw>federation</kw>
            <kw>cdni request routing</kw>
            <kw>cdni logging</kw>
            <kw>cdmi metadata</kw>
            <kw>cdni control</kw>
        </keywords>
        <abstract><p>This document presents a framework for Content Distribution Network Interconnection (CDNI).  The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs.  CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs.  The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents.  This document, in combination with RFC 6707, obsoletes RFC 3466.</p></abstract>
        <draft>draft-ietf-cdni-framework-14</draft>
        <obsoletes>
            <doc-id>RFC3466</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC7336</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7337</doc-id>
        <title>Content Distribution Network Interconnection (CDNI) Requirements</title>
        <author>
            <name>K. Leung</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.</p><p> The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.</p></abstract>
        <draft>draft-ietf-cdni-requirements-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC7337</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7338</doc-id>
        <title>Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks</title>
        <author>
            <name>F. Jounay</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Kamite</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Heron</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks.  The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation.  They are proposed as guidelines for the standardization of such mechanisms.  Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).</p></abstract>
        <draft>draft-ietf-pwe3-p2mp-pw-requirements-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7338</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7339</doc-id>
        <title>Session Initiation Protocol (SIP) Overload Control</title>
        <author>
            <name>V. Gurbani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Hilt</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Overload Control</kw>
        </keywords>
        <abstract><p>Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the SIP messages they receive.  Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload.  This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.</p></abstract>
        <draft>draft-ietf-soc-overload-control-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>soc</wg_acronym>
        <doi>10.17487/RFC7339</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7340</doc-id>
        <title>Secure Telephone Identity Problem Statement and Requirements</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>XMPP</kw>
            <kw>Secure Origin Identification</kw>
            <kw>Communication Security</kw>
            <kw>RTCWeb</kw>
            <kw>Problem Statement</kw>
            <kw>Real-Time Communication</kw>
        </keywords>
        <abstract><p>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</p></abstract>
        <draft>draft-ietf-stir-problem-statement-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC7340</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7341</doc-id>
        <title>DHCPv4-over-DHCPv6 (DHCP 4o6) Transport</title>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>M. Siodelski</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>transition</kw>
            <kw>softwire</kw>
            <kw>migration</kw>
            <kw>tunnel</kw>
            <kw>residual</kw>
            <kw>ipv4</kw>
            <kw>dhcpv6</kw>
            <kw>relay</kw>
            <kw>ipv6-only</kw>
        </keywords>
        <abstract><p>IPv4 connectivity is still needed as networks migrate towards IPv6.  Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only.  This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport.  Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv4-over-dhcpv6-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7341</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7342</doc-id>
        <title>Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers</title>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>I. Gashinsky</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.</p></abstract>
        <draft>draft-dunbar-armd-arp-nd-scaling-practices-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7342</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7343</doc-id>
        <title>An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)</title>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>HIPv2</kw>
            <kw>ORCHID</kw>
            <kw>CGA</kw>
            <kw>API</kw>
        </keywords>
        <abstract><p>This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.</p><p> The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.</p></abstract>
        <draft>draft-ietf-hip-rfc4843-bis-08</draft>
        <obsoletes>
            <doc-id>RFC4843</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9374</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC7343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7344</doc-id>
        <title>Automating DNSSEC Delegation Trust Maintenance</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>G. Barwood</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>key roll</kw>
            <kw>trust anchor</kw>
            <kw>CDS</kw>
            <kw>CDNSKEY</kw>
            <kw>DNSSEC</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel.  The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.</p></abstract>
        <draft>draft-ietf-dnsop-delegation-trust-maintainance-14</draft>
        <updated-by>
            <doc-id>RFC8078</doc-id>
            <doc-id>RFC9615</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7344</errata-url>
        <doi>10.17487/RFC7344</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7345</doc-id>
        <title>UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>I. Sedlacek</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>SIP</kw>
            <kw>DTLS</kw>
            <kw>UDPTL</kw>
            <kw>fax</kw>
            <kw>transport</kw>
        </keywords>
        <abstract><p>This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).</p></abstract>
        <draft>draft-ietf-mmusic-udptl-dtls-10</draft>
        <updated-by>
            <doc-id>RFC8842</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7346</doc-id>
        <title>IPv6 Multicast Address Scopes</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPv6 multicast address scopes</kw>
        </keywords>
        <abstract><p>This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.</p></abstract>
        <draft>draft-ietf-6man-multicast-scopes-07</draft>
        <updates>
            <doc-id>RFC4007</doc-id>
            <doc-id>RFC4291</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7346</errata-url>
        <doi>10.17487/RFC7346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7347</doc-id>
        <title>Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)</title>
        <author>
            <name>H. van Helvoort</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Ryoo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Zhang</name>
        </author>
        <author>
            <name>F. Huang</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.</p><p> This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.</p><p> The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.</p></abstract>
        <draft>draft-zulr-mpls-tp-linear-protection-switching-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7348</doc-id>
        <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
        <author>
            <name>M. Mahalingam</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <author>
            <name>K. Duda</name>
        </author>
        <author>
            <name>P. Agarwal</name>
        </author>
        <author>
            <name>L. Kreeger</name>
        </author>
        <author>
            <name>T. Sridhar</name>
        </author>
        <author>
            <name>M. Bursell</name>
        </author>
        <author>
            <name>C. Wright</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants.  The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers.  This memo documents the deployed VXLAN protocol for the benefit of the Internet community.</p></abstract>
        <draft>draft-mahalingam-dutt-dcops-vxlan-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7348</errata-url>
        <doi>10.17487/RFC7348</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7349</doc-id>
        <title>LDP Hello Cryptographic Authentication</title>
        <author>
            <name>L. Zheng</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages.  It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header.  This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.</p></abstract>
        <draft>draft-ietf-mpls-ldp-hello-crypto-auth-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7349</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7350</doc-id>
        <title>Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN).  It provides guidance on when and how to use DTLS with the currently standardized STUN usages.  It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol.  This document updates RFCs 5389 and 5928.</p></abstract>
        <draft>draft-ietf-tram-stun-dtls-05</draft>
        <updates>
            <doc-id>RFC5389</doc-id>
            <doc-id>RFC5928</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <doi>10.17487/RFC7350</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7351</doc-id>
        <title>A Media Type for XML Patch Operations</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Media Type</kw>
            <kw>XML Patch Operations</kw>
        </keywords>
        <abstract><p>The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document.  The XML patch document format builds on the foundations defined in RFC 5261.  This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.</p></abstract>
        <draft>draft-wilde-xml-patch-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7351</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7352</doc-id>
        <title>Sieve Email Filtering: Detecting Duplicate Deliveries</title>
        <author>
            <name>S. Bosch</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>sieve</kw>
            <kw>duplicate deliveries</kw>
        </keywords>
        <abstract><p>This document defines a new test command, "duplicate", for the Sieve email filtering language.  This test adds the ability to detect duplications.  The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses.  The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages.  For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message.</p></abstract>
        <draft>draft-ietf-appsawg-sieve-duplicate-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7353</doc-id>
        <title>Security Requirements for BGP Path Validation</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>BGP</kw>
            <kw>Security</kw>
            <kw>AS_PATH</kw>
            <kw>and RPKI</kw>
        </keywords>
        <abstract><p>This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.</p></abstract>
        <draft>draft-ietf-sidr-bgpsec-reqs-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC7353</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7354</doc-id>
        <title>Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace</title>
        <author>
            <name>A. Adolf</name>
        </author>
        <author>
            <name>P. Siebert</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project.  This document updates RFC 5328 with new registrant information.</p></abstract>
        <draft>draft-adolf-dvb-urn-upd-01</draft>
        <updates>
            <doc-id>RFC5328</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7354</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7355</doc-id>
        <title>Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)</title>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <author>
            <name>A. Roman</name>
        </author>
        <author>
            <name>S. Garcia</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments.  This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new "Transport Flag" for such SIP WebSocket transport.</p></abstract>
        <draft>draft-salgueiro-dispatch-websocket-sipclf-02</draft>
        <updates>
            <doc-id>RFC6873</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7355</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7356</doc-id>
        <title>IS-IS Flooding Scope Link State PDUs (LSPs)</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.</p><p> The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.</p></abstract>
        <draft>draft-ietf-isis-fs-lsp-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7356</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7357</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol</title>
        <author>
            <name>H. Zhai</name>
        </author>
        <author>
            <name>F. Hu</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>O. Stokes</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ESADI</kw>
            <kw>TRILL</kw>
            <kw>RBridge</kw>
            <kw>Address Learning</kw>
            <kw>Reachability</kw>
            <kw>MAC Addresses</kw>
        </keywords>
        <abstract><p>The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).</p><p> ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.</p></abstract>
        <draft>draft-ietf-trill-esadi-09</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7358</doc-id>
        <title>Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)</title>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode.  This document updates RFC 5036 to make that fact clear.  It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.</p></abstract>
        <draft>draft-ietf-mpls-ldp-applicability-label-adv-03</draft>
        <updates>
            <doc-id>RFC3212</doc-id>
            <doc-id>RFC4447</doc-id>
            <doc-id>RFC5036</doc-id>
            <doc-id>RFC5918</doc-id>
            <doc-id>RFC6388</doc-id>
            <doc-id>RFC7140</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7358</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7359</doc-id>
        <title>Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>August</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages.  That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination.  This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software.  Additionally, this document offers possible mitigations for this issue.</p></abstract>
        <draft>draft-ietf-opsec-vpn-leakages-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC7359</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7360</doc-id>
        <title>Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets.  The protocol transports data in the clear, although some parts of the packets can have obfuscated content.  Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets.  This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems.  It also describes how implementations of this proposal can coexist with current RADIUS systems.</p></abstract>
        <draft>draft-ietf-radext-dtls-13</draft>
        <updated-by>
            <doc-id>RFC9765</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC7360</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7361</doc-id>
        <title>LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)</title>
        <author>
            <name>P. Dutta</name>
        </author>
        <author>
            <name>F. Balus</name>
        </author>
        <author>
            <name>O. Stokes</name>
        </author>
        <author>
            <name>G. Calvignac</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>MAC flush message</kw>
            <kw>MAC Flush TLV</kw>
            <kw>MAC flushing</kw>
        </keywords>
        <abstract><p>RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes.  The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes.  This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned.  Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-ldp-mac-opt-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7361</errata-url>
        <doi>10.17487/RFC7361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7362</doc-id>
        <title>Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication</title>
        <author>
            <name>E. Ivov</name>
        </author>
        <author>
            <name>H. Kaplan</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>VoIP</kw>
            <kw>firewall traversal</kw>
        </keywords>
        <abstract><p>This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.</p><p> This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.</p><p> Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.</p></abstract>
        <draft>draft-ietf-mmusic-latching-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7362</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7363</doc-id>
        <title>Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)</title>
        <author>
            <name>J. Maenpaa</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>P2PSIP</kw>
            <kw>P2P</kw>
            <kw>Chord</kw>
        </keywords>
        <abstract><p>REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service.  Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data.  This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.</p></abstract>
        <draft>draft-ietf-p2psip-self-tuning-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7363</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7364</doc-id>
        <title>Problem Statement: Overlays for Network Virtualization</title>
        <author>
            <name>T. Narten</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Gray</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <author>
            <name>L. Kreeger</name>
        </author>
        <author>
            <name>M. Napierala</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach.  A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant.  Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks.  Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway).  Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated.  Use of an overlay-based approach enables scalable deployment on large network infrastructures.</p></abstract>
        <draft>draft-ietf-nvo3-overlay-problem-statement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC7364</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7365</doc-id>
        <title>Framework for Data Center (DC) Network Virtualization</title>
        <author>
            <name>M. Lasserre</name>
        </author>
        <author>
            <name>F. Balus</name>
        </author>
        <author>
            <name>T. Morin</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>nvo3</kw>
            <kw>network virtualization over layer 3</kw>
        </keywords>
        <abstract><p>This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.</p></abstract>
        <draft>draft-ietf-nvo3-framework-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC7365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7366</doc-id>
        <title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>P. Gutmann</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.</p></abstract>
        <draft>draft-ietf-tls-encrypt-then-mac-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7366</errata-url>
        <doi>10.17487/RFC7366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7367</doc-id>
        <title>Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process</title>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>J. Macker</name>
        </author>
        <author>
            <name>B. Adamson</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>Routing</kw>
            <kw>MANET</kw>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>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 for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc Networks (MANETs).  The SMF-MIB module also reports state information, performance information, and notifications.  In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.</p></abstract>
        <draft>draft-ietf-manet-smf-mib-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7367</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7368</doc-id>
        <title>IPv6 Home Networking Architecture Principles</title>
        <author>
            <name>T. Chown</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>J. Weil</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing.  The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements.  The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking.  The architecture describes the need for specific protocol extensions for certain additional functionality.  It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network.  There are no recommendations in this text for the IPv4 part of the network.</p></abstract>
        <draft>draft-ietf-homenet-arch-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <doi>10.17487/RFC7368</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7369</doc-id>
        <title>GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration</title>
        <author>
            <name>A. Takacs</name>
        </author>
        <author>
            <name>B. Gero</name>
        </author>
        <author>
            <name>H. Long</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>GELS</kw>
            <kw>Ethernet Label Switching</kw>
            <kw>PBB-TE</kw>
            <kw>connectivity monitoring</kw>
            <kw>OAM configuration</kw>
        </keywords>
        <abstract><p>The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs).  IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks.  CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms.  The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks.  This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework.  This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.</p></abstract>
        <draft>draft-ietf-ccamp-rsvp-te-eth-oam-ext-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7370</doc-id>
        <title>Updates to the IS-IS TLV Codepoints Registry</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Codepoint</kw>
        </keywords>
        <abstract><p>This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol.  It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.</p></abstract>
        <draft>draft-ietf-isis-tlv-codepoints-02</draft>
        <updated-by>
            <doc-id>RFC9352</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7370</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7371</doc-id>
        <title>Updates to the IPv6 Multicast Addressing Architecture</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv6 Multicast Flag Bits</kw>
            <kw>updated unicast-prefix-based address</kw>
            <kw>updated Embedded-RP</kw>
        </keywords>
        <abstract><p>This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.</p><p> This document updates RFCs 3956, 3306, and 4291.</p></abstract>
        <draft>draft-ietf-6man-multicast-addr-arch-update-08</draft>
        <updates>
            <doc-id>RFC3306</doc-id>
            <doc-id>RFC3956</doc-id>
            <doc-id>RFC4291</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7371</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7372</doc-id>
        <title>Email Authentication Status Codes</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.</p><p> This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.</p></abstract>
        <draft>draft-ietf-appsawg-email-auth-codes-07</draft>
        <updates>
            <doc-id>RFC7208</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7373</doc-id>
        <title>Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>information element</kw>
            <kw>unicode</kw>
        </keywords>
        <abstract><p>This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.</p></abstract>
        <draft>draft-ietf-ipfix-text-adt-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ipfix</wg_acronym>
        <doi>10.17487/RFC7373</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7374</doc-id>
        <title>Service Discovery Usage for REsource LOcation And Discovery (RELOAD)</title>
        <author>
            <name>J. Maenpaa</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>P2PSIP</kw>
            <kw>ReDiR</kw>
            <kw>P2P</kw>
            <kw>DHT</kw>
        </keywords>
        <abstract><p>REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940).  This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.</p></abstract>
        <draft>draft-ietf-p2psip-service-discovery-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7374</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7375</doc-id>
        <title>Secure Telephone Identity Threat Model</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Secure Origin Identification</kw>
            <kw>Communication Security</kw>
            <kw>RTCWeb</kw>
            <kw>Threat</kw>
            <kw>Real-Time Communication</kw>
        </keywords>
        <abstract><p>As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.</p></abstract>
        <draft>draft-ietf-stir-threats-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC7375</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7376</doc-id>
        <title>Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)</title>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>M. Perumal</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <date>
            <month>September</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.</p></abstract>
        <draft>draft-ietf-tram-auth-problems-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <doi>10.17487/RFC7376</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7377</doc-id>
        <title>IMAP4 Multimailbox SEARCH Extension</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>email</kw>
            <kw>search</kw>
            <kw>multiple mailboxes</kw>
            <kw>imapext</kw>
        </keywords>
        <abstract><p>The IMAP4 specification allows the searching of only the selected mailbox.  A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next.  This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox.  This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses.  This document updates RFC 4466 and obsoletes RFC 6237.</p></abstract>
        <draft>draft-ietf-appsawg-multimailbox-search-04</draft>
        <obsoletes>
            <doc-id>RFC6237</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4466</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7377</errata-url>
        <doi>10.17487/RFC7377</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7378</doc-id>
        <title>Trustworthy Location</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>B. Aboba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.</p><p> This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.</p></abstract>
        <draft>draft-ietf-ecrit-trustworthy-location-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC7378</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7379</doc-id>
        <title>Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge</title>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>W. Hao</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>J. Hudson</name>
        </author>
        <author>
            <name>H. Zhai</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology.  Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus.  This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.</p></abstract>
        <draft>draft-ietf-trill-active-active-connection-prob-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7379</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7380</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting</title>
        <author>
            <name>J. Tong</name>
        </author>
        <author>
            <name>C. Bi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TR 101 290</kw>
        </keywords>
        <abstract><p>An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data.  Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems.  This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP.  The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-psi-decodability-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7380</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7381</doc-id>
        <title>Enterprise IPv6 Deployment Guidelines</title>
        <author>
            <name>K. Chittimaneni</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>L. Howard</name>
        </author>
        <author>
            <name>V. Kuarsingh</name>
        </author>
        <author>
            <name>Y. Pouffary</name>
        </author>
        <author>
            <name>E. Vyncke</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>IPV6 migration transition enterprise</kw>
        </keywords>
        <abstract><p>Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks.  The administrators face different challenges than operators of Internet access providers and have reasons for different priorities.  The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network.  The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode.  This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.</p></abstract>
        <draft>draft-ietf-v6ops-enterprise-incremental-ipv6-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7381</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7382</doc-id>
        <title>Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>D. Kong</name>
        </author>
        <author>
            <name>K. Seo</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.</p></abstract>
        <draft>draft-ietf-sidr-cps-04</draft>
        <is-also>
            <doc-id>BCP0173</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC7382</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7383</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IP fragmentation</kw>
            <kw>NAT</kw>
            <kw>firewall</kw>
            <kw>PMTU discovery</kw>
        </keywords>
        <abstract><p>This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages.  This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-fragmentation-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC7383</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7384</doc-id>
        <title>Security Requirements of Time Protocols in Packet Switched Networks</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>ptp</kw>
            <kw>precision time protocol</kw>
            <kw>ntp</kw>
            <kw>network time protocol</kw>
        </keywords>
        <abstract><p>As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing.  This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP).  This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.</p></abstract>
        <draft>draft-ietf-tictoc-security-requirements-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tictoc</wg_acronym>
        <doi>10.17487/RFC7384</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7385</doc-id>
        <title>IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However, the RFC did not create a corresponding IANA registry.</p><p> There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.</p></abstract>
        <draft>draft-ietf-l3vpn-pmsi-registry-07</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8317</doc-id>
            <doc-id>RFC8338</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l3vpn</wg_acronym>
        <doi>10.17487/RFC7385</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7386</doc-id>
        <title>JSON Merge Patch</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>http</kw>
            <kw>json</kw>
            <kw>patch</kw>
            <kw>merge</kw>
        </keywords>
        <abstract><p>This specification defines the JSON merge patch format and processing rules.  The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.</p></abstract>
        <draft>draft-ietf-appsawg-json-merge-patch-07</draft>
        <obsoleted-by>
            <doc-id>RFC7396</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7386</errata-url>
        <doi>10.17487/RFC7386</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7387</doc-id>
        <title>A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network</title>
        <author>
            <name>R. Key</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Yong</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Delord</name>
        </author>
        <author>
            <name>F. Jounay</name>
        </author>
        <author>
            <name>L. Jin</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>mef</kw>
            <kw>etherhet lan</kw>
            <kw>e-lan</kw>
            <kw>metro ethernet forum</kw>
        </keywords>
        <abstract><p>This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network.  The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.</p></abstract>
        <draft>draft-ietf-l2vpn-etree-frwk-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC7387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7388</doc-id>
        <title>Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>A. Sehgal</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
        </keywords>
        <abstract><p>This document 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 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).</p></abstract>
        <draft>draft-ietf-6lo-lowpan-mib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC7388</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7389</doc-id>
        <title>Separation of Control and User Plane for Proxy Mobile IPv6</title>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Control and User Plane Split</kw>
            <kw>Control and User Plane Separation</kw>
            <kw>LMA User-Plane Address Mobility Option</kw>
        </keywords>
        <abstract><p>This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6).  Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4.  However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split.  To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA.  With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.</p></abstract>
        <draft>draft-ietf-netext-pmip-cp-up-separation-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7390</doc-id>
        <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>A. Rahman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Dijk</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>IP multicast</kw>
            <kw>RESTful</kw>
            <kw>Internet of Things (IoT)</kw>
        </keywords>
        <abstract><p>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks.  It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group).  This specification defines how CoAP should be used in a group communication context.  An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification.  Also, various use cases and corresponding protocol flows are provided to illustrate important concepts.  Finally, guidance is provided for deployment in various network topologies.</p></abstract>
        <draft>draft-ietf-core-groupcomm-25</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC7390</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7391</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Protocol Extensions</title>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>Protocol</kw>
            <kw>Extension</kw>
        </keywords>
        <abstract><p>Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions.  The ForCES protocol is extended with a table range operation and a new extension for error handling.  This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.</p></abstract>
        <draft>draft-ietf-forces-protoextension-06</draft>
        <updates>
            <doc-id>RFC5810</doc-id>
            <doc-id>RFC7121</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC7391</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7392</doc-id>
        <title>Explicit Path Routing for Dynamic Multi-Segment Pseudowires</title>
        <author>
            <name>P. Dutta</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Pseudowire</kw>
            <kw>MS-PW</kw>
            <kw>explicit route</kw>
        </keywords>
        <abstract><p>When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs.  This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.</p></abstract>
        <draft>draft-ietf-pwe3-mspw-er-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pwe3</wg_acronym>
        <doi>10.17487/RFC7392</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7393</doc-id>
        <title>Using the Port Control Protocol (PCP) to Update Dynamic DNS</title>
        <author>
            <name>X. Deng</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>J. Huang</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>address sharing</kw>
            <kw>CGN</kw>
            <kw>service continuity</kw>
            <kw>service availability</kw>
            <kw>user-generated content</kw>
            <kw>address-sharing issues</kw>
            <kw>DS-Lite</kw>
            <kw>service delivery in CGN contexts</kw>
        </keywords>
        <abstract><p>This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition.  Both issues and possible solutions are documented in this memo.</p></abstract>
        <draft>draft-deng-pcp-ddns-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7393</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7394</doc-id>
        <title>Definition of Time to Live TLV for LSP-Ping Mechanisms</title>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>S. Saxena</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks.  However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP.  This document defines a TLV to address this shortcoming.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-ttl-tlv-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7394</errata-url>
        <doi>10.17487/RFC7394</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7395</doc-id>
        <title>An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket</title>
        <author>
            <name>L. Stout</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Moffitt</name>
        </author>
        <author>
            <name>E. Cestari</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>WebSocket</kw>
            <kw>XMPP</kw>
        </keywords>
        <abstract><p>This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer.  A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.</p></abstract>
        <draft>draft-ietf-xmpp-websocket-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xmpp</wg_acronym>
        <doi>10.17487/RFC7395</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7396</doc-id>
        <title>JSON Merge Patch</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Snell</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>http</kw>
            <kw>json</kw>
            <kw>patch</kw>
            <kw>merge</kw>
        </keywords>
        <abstract><p>This specification defines the JSON merge patch format and processing rules.  The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.</p></abstract>
        <draft>draft-ietf-rfc7386bis-00</draft>
        <obsoletes>
            <doc-id>RFC7386</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7396</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7397</doc-id>
        <title>Report from the Smart Object Security Workshop</title>
        <author>
            <name>J. Gilger</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Smart Objects</kw>
            <kw>Internet of Things</kw>
            <kw>Workshop</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.</p><p> This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.</p></abstract>
        <draft>draft-gilger-smart-object-security-workshop-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7397</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7398</doc-id>
        <title>A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>T. Burbridge</name>
        </author>
        <author>
            <name>S. Crawford</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>LMAP</kw>
            <kw>performance metrics</kw>
        </keywords>
        <abstract><p>This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics.  Other similar measurement projects may also be able to use the extensions described here for measurement point location.  The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.</p></abstract>
        <draft>draft-ietf-ippm-lmap-path-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7398</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7399</doc-id>
        <title>Unanswered Questions in the Path Computation Element Architecture</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>October</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>SDN</kw>
            <kw>Software Defined Networking</kw>
            <kw>H-PCE</kw>
            <kw>Hierarchical PCE</kw>
            <kw>VNTM</kw>
            <kw>Virtual Network Topology Manager</kw>
            <kw>ABNO</kw>
            <kw>Application-Based Network Operation</kw>
            <kw>TE</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.</p><p> These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.</p><p> This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.</p></abstract>
        <draft>draft-ietf-pce-questions-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7399</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7400</doc-id>
        <title>6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>Embedded Internet</kw>
            <kw>Sensor Network</kw>
            <kw>WSN</kw>
            <kw>Constrained node</kw>
            <kw>Constrained network</kw>
            <kw>Constrained-node network</kw>
            <kw>LLN</kw>
            <kw>LoWPAN</kw>
            <kw>packet encoding</kw>
            <kw>capability indication</kw>
            <kw>6CIO</kw>
            <kw>LZ77</kw>
            <kw>RFC 6282</kw>
            <kw>RFC 4944</kw>
            <kw>adaptation layer</kw>
            <kw>IEEE 802.15.4</kw>
        </keywords>
        <abstract><p>RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network").  The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.</p></abstract>
        <draft>draft-ietf-6lo-ghc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC7400</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7401</doc-id>
        <title>Host Identity Protocol Version 2 (HIPv2)</title>
        <author>
            <name>R. Moskowitz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Heer</name>
        </author>
        <author>
            <name>P. Jokela</name>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>128</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>IP-layer state</kw>
            <kw>integrity protection</kw>
            <kw>optional encryption</kw>
        </keywords>
        <abstract><p>This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.</p><p> This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.</p></abstract>
        <draft>draft-ietf-hip-rfc5201-bis-20</draft>
        <obsoletes>
            <doc-id>RFC5201</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8002</doc-id>
            <doc-id>RFC9374</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7401</errata-url>
        <doi>10.17487/RFC7401</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7402</doc-id>
        <title>Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)</title>
        <author>
            <name>P. Jokela</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>J. Melen</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>user data packets</kw>
        </keywords>
        <abstract><p>This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).  This document obsoletes RFC 5202.</p></abstract>
        <draft>draft-ietf-hip-rfc5202-bis-07</draft>
        <obsoletes>
            <doc-id>RFC5202</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC7402</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7403</doc-id>
        <title>A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target.  A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator.  This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back-to-back user agents (B2BUAs).</p></abstract>
        <draft>draft-ietf-straw-sip-traceroute-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>straw</wg_acronym>
        <doi>10.17487/RFC7403</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7404</doc-id>
        <title>Using Only Link-Local Addressing inside an IPv6 Network</title>
        <author>
            <name>M. Behringer</name>
        </author>
        <author>
            <name>E. Vyncke</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IPv6 security routing</kw>
            <kw>Link-Local</kw>
            <kw>Routing Protocol</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers.  This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.</p></abstract>
        <draft>draft-ietf-opsec-lla-only-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7404</errata-url>
        <doi>10.17487/RFC7404</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7405</doc-id>
        <title>Case-Sensitive String Support in ABNF</title>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>BNF</kw>
            <kw>ABNF Syntax</kw>
        </keywords>
        <abstract><p>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</p></abstract>
        <draft>draft-kyzivat-case-sensitive-abnf-02</draft>
        <updates>
            <doc-id>RFC5234</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7405</errata-url>
        <doi>10.17487/RFC7405</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7406</doc-id>
        <title>Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S. McCann</name>
        </author>
        <author>
            <name>G. Bajko</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Kroeselberg</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.</p></abstract>
        <draft>draft-ietf-ecrit-unauthenticated-access-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC7406</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7407</doc-id>
        <title>A YANG Data Model for SNMP Configuration</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>88</page-count>
        <abstract><p>This document defines a collection of YANG definitions for configuring SNMP engines.</p></abstract>
        <draft>draft-ietf-netmod-snmp-cfg-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7407</errata-url>
        <doi>10.17487/RFC7407</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7408</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Model Extension</title>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>Model</kw>
            <kw>Extension</kw>
        </keywords>
        <abstract><p>This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures.  It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties.  The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.</p></abstract>
        <draft>draft-ietf-forces-model-extension-05</draft>
        <updates>
            <doc-id>RFC5812</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7408</errata-url>
        <doi>10.17487/RFC7408</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7409</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Packet Parallelization</title>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>Model</kw>
            <kw>Extension</kw>
        </keywords>
        <abstract><p>Many network devices support parallel packet processing.  This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).</p></abstract>
        <draft>draft-ietf-forces-packet-parallelization-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>forces</wg_acronym>
        <doi>10.17487/RFC7409</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7410</doc-id>
        <title>A Property Types Registry for the Authentication-Results Header Field</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Authentication-Results</kw>
            <kw>Reputation</kw>
        </keywords>
        <abstract><p>This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.</p></abstract>
        <draft>draft-ietf-appsawg-authres-ptypes-registry-04</draft>
        <obsoleted-by>
            <doc-id>RFC7601</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC7001</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7410</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7411</doc-id>
        <title>Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers</title>
        <author>
            <name>T. Schmidt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>D. Liu</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>Mobility</kw>
            <kw>IPv6</kw>
            <kw>PIM</kw>
            <kw>MLD</kw>
            <kw>Group Communication</kw>
        </keywords>
        <abstract><p>Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.</p><p> This document updates RFC 5568, "Mobile IPv6 Fast Handovers".</p></abstract>
        <draft>draft-ietf-multimob-fmipv6-pfmipv6-multicast-10</draft>
        <updates>
            <doc-id>RFC5568</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>multimob</wg_acronym>
        <doi>10.17487/RFC7411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7412</doc-id>
        <title>Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection</title>
        <author>
            <name>Y. Weingarten</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>P. Pan</name>
        </author>
        <author>
            <name>J. Ryoo</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support.  This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework").  This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.</p></abstract>
        <draft>draft-ietf-mpls-smp-requirements-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7412</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7413</doc-id>
        <title>TCP Fast Open</title>
        <author>
            <name>Y. Cheng</name>
        </author>
        <author>
            <name>J. Chu</name>
        </author>
        <author>
            <name>S. Radhakrishnan</name>
        </author>
        <author>
            <name>A. Jain</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document describes an experimental TCP mechanism called TCP Fast Open (TFO).  TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged.  However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.  Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.</p></abstract>
        <draft>draft-ietf-tcpm-fastopen-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7413</errata-url>
        <doi>10.17487/RFC7413</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7414</doc-id>
        <title>A Roadmap for Transmission Control Protocol (TCP) Specification Documents</title>
        <author>
            <name>M. Duke</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>W. Eddy</name>
        </author>
        <author>
            <name>E. Blanton</name>
        </author>
        <author>
            <name>A. Zimmermann</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>TCP Roadmap</kw>
        </keywords>
        <abstract><p>This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.</p><p> This document obsoletes RFC 4614.</p></abstract>
        <draft>draft-ietf-tcpm-tcp-rfc4614bis-08</draft>
        <obsoletes>
            <doc-id>RFC4614</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7805</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC7414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7415</doc-id>
        <title>Session Initiation Protocol (SIP) Rate Control</title>
        <author>
            <name>E. Noel</name>
        </author>
        <author>
            <name>P. Williams</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads.  A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed.  Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.</p></abstract>
        <draft>draft-ietf-soc-overload-rate-control-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>soc</wg_acronym>
        <doi>10.17487/RFC7415</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7416</doc-id>
        <title>A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)</title>
        <author>
            <name>T. Tsao</name>
        </author>
        <author>
            <name>R. Alexander</name>
        </author>
        <author>
            <name>M. Dohler</name>
        </author>
        <author>
            <name>V. Daza</name>
        </author>
        <author>
            <name>A. Lozano</name>
        </author>
        <author>
            <name>M. Richardson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>LLN</kw>
            <kw>ROLL</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.</p></abstract>
        <draft>draft-ietf-roll-security-threats-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC7416</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7417</doc-id>
        <title>Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains</title>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>A. Bhargava</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>generic aggregate rsvp</kw>
        </keywords>
        <abstract><p>This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.</p></abstract>
        <draft>draft-ietf-tsvwg-rsvp-pcn-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC7417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7418</doc-id>
        <title>An IRTF Primer for IETF Participants</title>
        <author>
            <name>S. Dawkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Research Group</kw>
        </keywords>
        <abstract><p>This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF).  This document emphasizes differences in expectations between the two organizations.</p></abstract>
        <draft>draft-dawkins-irtf-newrg-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7418</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7419</doc-id>
        <title>Common Interval Support in Bidirectional Forwarding Detection</title>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>M. Binderberger</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>hardware</kw>
            <kw>interval</kw>
            <kw>timer</kw>
        </keywords>
        <abstract><p>Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.</p><p> This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.</p></abstract>
        <draft>draft-ietf-bfd-intervals-05</draft>
        <updates>
            <doc-id>RFC5880</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC7419</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7420</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module</title>
        <author>
            <name>A. Koushik</name>
        </author>
        <author>
            <name>E. Stephan</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>J. Hardwick</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>PCE</kw>
            <kw>PCEP</kw>
        </keywords>
        <abstract><p>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 modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.</p></abstract>
        <draft>draft-ietf-pce-pcep-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7420</errata-url>
        <doi>10.17487/RFC7420</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7421</doc-id>
        <title>Analysis of the 64-bit Boundary in IPv6 Addressing</title>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>A. Petrescu</name>
        </author>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet.  Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix.  This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.</p></abstract>
        <draft>draft-ietf-6man-why64-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7421</errata-url>
        <doi>10.17487/RFC7421</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7422</doc-id>
        <title>Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments</title>
        <author>
            <name>C. Donley</name>
        </author>
        <author>
            <name>C. Grundemann</name>
        </author>
        <author>
            <name>V. Sarawat</name>
        </author>
        <author>
            <name>K. Sundaresan</name>
        </author>
        <author>
            <name>O. Vautrin</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response).  Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations.  CGN port assignments are often per connection, but they could optionally use port ranges.  Research indicates that per-connection logging is not scalable in many residential broadband services.  This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response.  IPv6 is, of course, the preferred solution.  While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4.  This note addresses the IPv4 part of the network when a CGN solution is in use.</p></abstract>
        <draft>draft-donley-behave-deterministic-cgn-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7422</errata-url>
        <doi>10.17487/RFC7422</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7423</doc-id>
        <title>Diameter Applications Design Guidelines</title>
        <author>
            <name>L. Morand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Fajardo</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>November</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>AAA</kw>
            <kw>Authentication</kw>
            <kw>Authorization</kw>
            <kw>Accounting</kw>
        </keywords>
        <abstract><p>The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications.  This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter.  Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.</p></abstract>
        <draft>draft-ietf-dime-app-design-guide-28</draft>
        <is-also>
            <doc-id>BCP0193</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7423</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7424</doc-id>
        <title>Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks</title>
        <author>
            <name>R. Krishnan</name>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>N. So</name>
        </author>
        <author>
            <name>B. Khasnabish</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications.  In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling.  This document explores some of the mechanisms useful for achieving this.</p></abstract>
        <draft>draft-ietf-opsawg-large-flow-load-balancing-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7425</doc-id>
        <title>Adobe's RTMFP Profile for Flash Communication</title>
        <author>
            <name>M. Thornburgh</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <abstract><p>This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications.  Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.</p></abstract>
        <draft>draft-thornburgh-rtmfp-flash-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7426</doc-id>
        <title>Software-Defined Networking (SDN): Layers and Architecture Terminology</title>
        <author>
            <name>E. Haleplidis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Pentikousis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Denazis</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>O. Koufopavlou</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Software-defined Networking</kw>
            <kw>SDN</kw>
            <kw>Programmable Networks</kw>
            <kw>Architecture</kw>
            <kw>Layer</kw>
            <kw>Terminology</kw>
        </keywords>
        <abstract><p>Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces.  SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane.  This separation allows faster innovation cycles at both planes as experience has already shown.  However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other.  This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.</p></abstract>
        <draft>draft-irtf-sdnrg-layer-terminology-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7426</errata-url>
        <doi>10.17487/RFC7426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7427</doc-id>
        <title>Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>J. Snyder</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>IKE</kw>
            <kw>IKEv2</kw>
            <kw>Signature</kw>
            <kw>Authentication</kw>
            <kw>RSA</kw>
            <kw>DSS</kw>
            <kw>DSA</kw>
            <kw>ECDSA</kw>
            <kw>SASSA-PSS</kw>
            <kw>PKIX</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA).  The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group.  This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation.  This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.</p></abstract>
        <draft>draft-kivinen-ipsecme-signature-auth-07</draft>
        <updates>
            <doc-id>RFC7296</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7427</errata-url>
        <doi>10.17487/RFC7427</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7428</doc-id>
        <title>Transmission of IPv6 Packets over ITU-T G.9959 Networks</title>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>J. Buron</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.</p></abstract>
        <draft>draft-ietf-6lo-lowpanz-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC7428</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7429</doc-id>
        <title>Distributed Mobility Management: Current Practices and Gap Analysis</title>
        <author>
            <name>D. Liu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JC. Zuniga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Seite</name>
        </author>
        <author>
            <name>H. Chan</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>DMM</kw>
            <kw>Distributed Mobility Management</kw>
            <kw>anchor</kw>
            <kw>gap analysis</kw>
            <kw>best practices</kw>
        </keywords>
        <abstract><p>This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment.  It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.</p></abstract>
        <draft>draft-ietf-dmm-best-practices-gap-analysis-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC7429</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7430</doc-id>
        <title>Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>C. Paasch</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <author>
            <name>C. Raiciu</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MPTCP</kw>
            <kw>security</kw>
            <kw>threat analysis</kw>
        </keywords>
        <abstract><p>This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.</p></abstract>
        <draft>draft-ietf-mptcp-attacks-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7430</errata-url>
        <doi>10.17487/RFC7430</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7431</doc-id>
        <title>Multicast-Only Fast Reroute</title>
        <author>
            <name>A. Karan</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services.  This document describes a mechanism for minimizing packet loss in a network when node or link failures occur.  Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).</p></abstract>
        <draft>draft-ietf-rtgwg-mofrr-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC7431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7432</doc-id>
        <title>BGP MPLS-Based Ethernet VPN</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>A. Isaac</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <abstract><p>This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN).  The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</p></abstract>
        <draft>draft-ietf-l2vpn-evpn-11</draft>
        <updated-by>
            <doc-id>RFC8584</doc-id>
            <doc-id>RFC9161</doc-id>
            <doc-id>RFC9572</doc-id>
            <doc-id>RFC9573</doc-id>
            <doc-id>RFC9746</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7432</errata-url>
        <doi>10.17487/RFC7432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7433</doc-id>
        <title>A Mechanism for Transporting User-to-User Call Control Information in SIP</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>UUI</kw>
            <kw>Package</kw>
            <kw>Content</kw>
            <kw>Encoding</kw>
            <kw>Media</kw>
        </keywords>
        <abstract><p>There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment.  This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session.  The syntax and semantics for the UUI data used by a specific application are defined by a UUI package.  This UUI data is opaque to SIP and its function is unrelated to any basic SIP function.  This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.</p></abstract>
        <draft>draft-ietf-cuss-sip-uui-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>cuss</wg_acronym>
        <doi>10.17487/RFC7433</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7434</doc-id>
        <title>Interworking ISDN Call Control User Information with SIP</title>
        <author>
            <name>K. Drage</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>UUS Supplementary Service</kw>
        </keywords>
        <abstract><p>The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.</p><p> This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.</p><p> The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.</p></abstract>
        <draft>draft-ietf-cuss-sip-uui-isdn-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>cuss</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7434</errata-url>
        <doi>10.17487/RFC7434</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7435</doc-id>
        <title>Opportunistic Security: Some Protection Most of the Time</title>
        <author>
            <name>V. Dukhovni</name>
        </author>
        <date>
            <month>December</month>
            <year>2014</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document defines the concept "Opportunistic Security" in the context of communications protocols.  Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</p></abstract>
        <draft>draft-dukhovni-opportunistic-security-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7435</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7436</doc-id>
        <title>IP-Only LAN Service (IPLS)</title>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>G. Heron</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.</p><p> The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.</p></abstract>
        <draft>draft-ietf-l2vpn-ipls-16</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2vpn</wg_acronym>
        <doi>10.17487/RFC7436</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7437</doc-id>
        <title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Internet Architecture Board</kw>
            <kw>Engineering Steering Group</kw>
            <kw>nomcom</kw>
            <kw>IAOC</kw>
        </keywords>
        <abstract><p>The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document.  This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.</p></abstract>
        <draft>draft-kucherawy-rfc3777bis-04</draft>
        <obsoletes>
            <doc-id>RFC3777</doc-id>
            <doc-id>RFC5078</doc-id>
            <doc-id>RFC5633</doc-id>
            <doc-id>RFC5680</doc-id>
            <doc-id>RFC6859</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8713</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8318</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7437</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7438</doc-id>
        <title>Multipoint LDP (mLDP) In-Band Signaling with Wildcards</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>A. Gulko</name>
        </author>
        <author>
            <name>U. Joorde</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>There are scenarios in which an IP multicast tree traverses an MPLS domain.  In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain.  Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP).  However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP.  This document specifies the procedures to support these functions.  It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP.  Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document.  This document updates RFCs 6826 and 7246.</p></abstract>
        <draft>draft-ietf-mpls-mldp-in-band-wildcard-encoding-03</draft>
        <updates>
            <doc-id>RFC6826</doc-id>
            <doc-id>RFC7246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7438</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7439</doc-id>
        <title>Gap Analysis for Operating IPv6-Only MPLS Networks</title>
        <author>
            <name>W. George</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LDP</kw>
            <kw>IPv6</kw>
            <kw>RSVP</kw>
            <kw>L3VPN</kw>
            <kw>L2VPN</kw>
        </keywords>
        <abstract><p>This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.</p><p> In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.</p></abstract>
        <draft>draft-ietf-mpls-ipv6-only-gap-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7439</errata-url>
        <doi>10.17487/RFC7439</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7440</doc-id>
        <title>TFTP Windowsize Option</title>
        <author>
            <name>P. Masotta</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.</p><p> This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).</p></abstract>
        <draft>draft-masotta-tftpexts-windowsize-opt-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7440</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7441</doc-id>
        <title>Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes</title>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>U. Joorde</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Many service providers offer "BGP/MPLS IP VPN" service to their customers.  Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs.  It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs.  This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic.  Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances.  This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions.  This document updates RFC 6514.</p></abstract>
        <draft>draft-ietf-l3vpn-mvpn-mldp-nlri-10</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7441</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7442</doc-id>
        <title>Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>R. Li</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs).  This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).</p></abstract>
        <draft>draft-ietf-mpls-pim-sm-over-mldp-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7442</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7443</doc-id>
        <title>Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages</title>
        <author>
            <name>P. Patil</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <date>
            <month>January</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection.  ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS).</p></abstract>
        <draft>draft-ietf-tram-alpn-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <doi>10.17487/RFC7443</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7444</doc-id>
        <title>Security Labels in Internet Email</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>email</kw>
            <kw>header fields</kw>
            <kw>ESS</kw>
            <kw>Security Label</kw>
            <kw>Confidential Label</kw>
            <kw>Message Sensitivity</kw>
        </keywords>
        <abstract><p>This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message.  This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message.  This document also describes a header field, SIO-Label-History, for recording changes in the message's label.</p></abstract>
        <draft>draft-zeilenga-email-seclabel-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7444</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7445</doc-id>
        <title>Analysis of Failure Cases in IPv6 Roaming Scenarios</title>
        <author>
            <name>G. Chen</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>D. Michaud</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Mobile Network</kw>
            <kw>Dual Stack</kw>
            <kw>IPv6-only</kw>
        </keywords>
        <abstract><p>This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios.  The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-roaming-analysis-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7445</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7446</doc-id>
        <title>Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>W. Imajuku</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>WSON</kw>
            <kw>RWA</kw>
        </keywords>
        <abstract><p>This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs).  The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs.  This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments.  Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed.</p></abstract>
        <draft>draft-ietf-ccamp-rwa-info-24</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7446</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7447</doc-id>
        <title>Deprecation of BGP Entropy Label Capability Attribute</title>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>The BGP Entropy Label Capability attribute is defined in RFC 6790.  Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice.  This specification deprecates the attribute.  A forthcoming document will propose a replacement.</p></abstract>
        <draft>draft-ietf-mpls-deprecate-bgp-entropy-label-02</draft>
        <updates>
            <doc-id>RFC6790</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7447</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7448</doc-id>
        <title>MIB Transfer from the IETF to the IEEE 802.3 WG</title>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Ethernet</kw>
            <kw>IEEE</kw>
        </keywords>
        <abstract><p>This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG).  This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.</p></abstract>
        <draft>draft-ietf-opsawg-mibs-to-ieee80231-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7448</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7449</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Martensson</name>
        </author>
        <author>
            <name>T. Takeda</name>
        </author>
        <author>
            <name>T. Tsuritani</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs).  Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process.  From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation.  Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.</p></abstract>
        <draft>draft-ietf-pce-wson-routing-wavelength-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7449</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7450</doc-id>
        <title>Automatic Multicast Tunneling</title>
        <author>
            <name>G. Bumgardner</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>AMT</kw>
            <kw>IGMPv2</kw>
            <kw>IGMPv3</kw>
            <kw>MLDv1</kw>
            <kw>MLDv2</kw>
            <kw>ASM</kw>
            <kw>SSM</kw>
            <kw>amt gateway</kw>
            <kw>amt relay</kw>
            <kw>multicast replication</kw>
            <kw>multicast encapsulation</kw>
        </keywords>
        <abstract><p>This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.</p><p> The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.</p></abstract>
        <draft>draft-ietf-mboned-auto-multicast-18</draft>
        <updated-by>
            <doc-id>RFC8777</doc-id>
            <doc-id>RFC9601</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC7450</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7451</doc-id>
        <title>Extension Registry for the Extensible Provisioning Protocol</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>host</kw>
            <kw>contact</kw>
        </keywords>
        <abstract><p>The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol.  It does not, however, describe how those extensions are managed.  This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.</p></abstract>
        <draft>draft-ietf-eppext-reg-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>eppext</wg_acronym>
        <doi>10.17487/RFC7451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7452</doc-id>
        <title>Architectural Considerations in Smart Object Networking</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IAB Statement</kw>
            <kw>Smart Objects</kw>
        </keywords>
        <abstract><p>The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.</p><p> This document offers guidance to engineers designing Internet- connected smart objects.</p></abstract>
        <draft>draft-iab-smart-object-architecture-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7452</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7453</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)</title>
        <author>
            <name>V. Mahalingam</name>
        </author>
        <author>
            <name>K. Sampath</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <abstract><p>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 and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.</p></abstract>
        <draft>draft-ietf-mpls-tp-te-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7453</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7454</doc-id>
        <title>BGP Operations and Security</title>
        <author>
            <name>J. Durand</name>
        </author>
        <author>
            <name>I. Pepelnjak</name>
        </author>
        <author>
            <name>G. Doering</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.</p><p> This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.</p></abstract>
        <draft>draft-ietf-opsec-bgp-security-07</draft>
        <is-also>
            <doc-id>BCP0194</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC7454</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7455</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Fault Management</title>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>N. Finn</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>D. Kumar</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>Fault</kw>
            <kw>Continuity</kw>
            <kw>Connectivity</kw>
            <kw>OAM</kw>
            <kw>CFM</kw>
            <kw>MEP</kw>
            <kw>CCM</kw>
        </keywords>
        <abstract><p>This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management.  Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible.  Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1.  This document updates RFC 6325.</p></abstract>
        <draft>draft-ietf-trill-oam-fm-11</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7455</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7456</doc-id>
        <title>Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>D. Kumar</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM).  It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies.  This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.</p></abstract>
        <draft>draft-ietf-trill-loss-delay-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7457</doc-id>
        <title>Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>R. Holz</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Transport Layer Security</kw>
            <kw>TLS</kw>
            <kw>Datagram TLS</kw>
            <kw>DTLS</kw>
            <kw>Secure Sockets Layer</kw>
            <kw>SSL</kw>
            <kw>security attacks</kw>
        </keywords>
        <abstract><p>Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation.  This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).</p></abstract>
        <draft>draft-ietf-uta-tls-attacks-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7457</errata-url>
        <doi>10.17487/RFC7457</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7458</doc-id>
        <title>Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core</title>
        <author>
            <name>R. Valmikam</name>
        </author>
        <author>
            <name>R. Koodli</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Mobile Networks</kw>
            <kw>3GPP</kw>
            <kw>EAP</kw>
            <kw>EPC</kw>
            <kw>Handover</kw>
            <kw>Identity</kw>
            <kw>APN</kw>
        </keywords>
        <abstract><p>With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.</p><p> The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.</p></abstract>
        <draft>draft-ietf-netext-wifi-epc-eap-attributes-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7459</doc-id>
        <title>Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.</p><p> This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.</p></abstract>
        <draft>draft-ietf-geopriv-uncertainty-04</draft>
        <updates>
            <doc-id>RFC3693</doc-id>
            <doc-id>RFC4119</doc-id>
            <doc-id>RFC5491</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>geopriv</wg_acronym>
        <doi>10.17487/RFC7459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7460</doc-id>
        <title>Monitoring and Control MIB for Power and Energy</title>
        <author>
            <name>M. Chandramouli</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>B. Schoening</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>T. Dietz</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>IANAPowerStateSet-MIB</kw>
            <kw>ENERGY-OBJECT-MIB</kw>
            <kw>POWER-ATTRIBUTES-MIB</kw>
        </keywords>
        <abstract><p>This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.</p></abstract>
        <draft>draft-ietf-eman-energy-monitoring-mib-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <doi>10.17487/RFC7460</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7461</doc-id>
        <title>Energy Object Context MIB</title>
        <author>
            <name>J. Parello</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>M. Chandramouli</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>management information base</kw>
            <kw>ENERGY-OBJECT-CONTEXT-MIB</kw>
            <kw>IANA-ENERGY-RELATION-MIB</kw>
        </keywords>
        <abstract><p>This document defines a subset of a Management Information Base (MIB) for energy management of devices.  The module addresses device identification, context information, and the energy relationships between devices.</p></abstract>
        <draft>draft-ietf-eman-energy-aware-mib-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <doi>10.17487/RFC7461</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7462</doc-id>
        <title>URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)</title>
        <author>
            <name>L. Liess</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>D. Worley</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <abstract><p>The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.</p><p> This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.</p></abstract>
        <draft>draft-ietf-salud-alert-info-urns-14</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>salud</wg_acronym>
        <doi>10.17487/RFC7462</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7463</doc-id>
        <title>Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)</title>
        <author>
            <name>A. Johnston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Soroushnejad</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Venkataramanan</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <abstract><p>This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA).  When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines.  This feature is commonly offered in IP Centrex services and IP Private Branch Exchange (IPBX) offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment.  This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group.  This document discusses use cases, lists requirements, and defines extensions to implement this feature.  This specification updates RFCs 3261 and 4235.</p></abstract>
        <draft>draft-ietf-bliss-shared-appearances-15</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC4235</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>bliss</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7463</errata-url>
        <doi>10.17487/RFC7463</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7464</doc-id>
        <title>JavaScript Object Notation (JSON) Text Sequences</title>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>sequence</kw>
            <kw>online</kw>
            <kw>streaming</kw>
            <kw>log file</kw>
        </keywords>
        <abstract><p>This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq".  A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).</p></abstract>
        <draft>draft-ietf-json-text-sequence-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>json</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7464</errata-url>
        <doi>10.17487/RFC7464</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7465</doc-id>
        <title>Prohibiting RC4 Cipher Suites</title>
        <author>
            <name>A. Popov</name>
        </author>
        <date>
            <month>February</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections.  This applies to all TLS versions.  This document updates RFCs 5246, 4346, and 2246.</p></abstract>
        <draft>draft-ietf-tls-prohibiting-rc4-01</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC4346</doc-id>
            <doc-id>RFC2246</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC7465</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7466</doc-id>
        <title>An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>NHDP</kw>
            <kw>OLSRv2</kw>
            <kw>link quality</kw>
        </keywords>
        <abstract><p>The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.</p><p> NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.</p><p> This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".</p></abstract>
        <draft>draft-ietf-manet-nhdp-optimization-04</draft>
        <updates>
            <doc-id>RFC6130</doc-id>
            <doc-id>RFC7181</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7466</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7467</doc-id>
        <title>URN Namespace for the North Atlantic Treaty Organization (NATO)</title>
        <author>
            <name>A. Murdock</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406.  At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.</p></abstract>
        <draft>draft-murdock-nato-nid-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7467</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7468</doc-id>
        <title>Textual Encodings of PKIX, PKCS, and CMS Structures</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>S. Leonard</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS).  The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed.  This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.</p></abstract>
        <draft>draft-josefsson-pkix-textual-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7468</errata-url>
        <doi>10.17487/RFC7468</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7469</doc-id>
        <title>Public Key Pinning Extension for HTTP</title>
        <author>
            <name>C. Evans</name>
        </author>
        <author>
            <name>C. Palmer</name>
        </author>
        <author>
            <name>R. Sleevi</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>pin</kw>
        </keywords>
        <abstract><p>This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time.  During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host.  By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.</p></abstract>
        <draft>draft-ietf-websec-key-pinning-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>websec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7469</errata-url>
        <doi>10.17487/RFC7469</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7470</doc-id>
        <title>Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol</title>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.</p><p> This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.</p><p> This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.</p></abstract>
        <draft>draft-ietf-pce-rfc7150bis-01</draft>
        <obsoletes>
            <doc-id>RFC7150</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9752</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7470</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7471</doc-id>
        <title>OSPF Traffic Engineering (TE) Metric Extensions</title>
        <author>
            <name>S. Giacalone</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.</p><p> This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.</p><p> Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.</p></abstract>
        <draft>draft-ietf-ospf-te-metric-extensions-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7471</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7472</doc-id>
        <title>Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme</title>
        <author>
            <name>I. McDonald</name>
        </author>
        <author>
            <name>M. Sweet</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.</p><p> This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.</p></abstract>
        <draft>draft-mcdonald-ipps-uri-scheme-18</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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7472</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7473</doc-id>
        <title>Controlling State Advertisements of Non-negotiated LDP Applications</title>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs).  When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP).  This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.</p></abstract>
        <draft>draft-ietf-mpls-ldp-ip-pw-capability-09</draft>
        <updated-by>
            <doc-id>RFC8223</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7473</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7474</doc-id>
        <title>Security Extension for OSPFv2 When Using Manual Key Management</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>cryptographic authentication</kw>
            <kw>security</kw>
            <kw>replay attacks</kw>
        </keywords>
        <abstract><p>The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.</p><p> This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.</p></abstract>
        <draft>draft-ietf-ospf-security-extension-manual-keying-11</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
            <doc-id>RFC5709</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7475</doc-id>
        <title>Increasing the Number of Area Directors in an IETF Area</title>
        <author>
            <name>S. Dawkins</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area".  This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).</p></abstract>
        <draft>draft-dawkins-iesg-one-or-more-05</draft>
        <updates>
            <doc-id>RFC2026</doc-id>
            <doc-id>RFC2418</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7475</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7476</doc-id>
        <title>Information-Centric Networking: Baseline Scenarios</title>
        <author>
            <name>K. Pentikousis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Ohlman</name>
        </author>
        <author>
            <name>D. Corujo</name>
        </author>
        <author>
            <name>G. Boggia</name>
        </author>
        <author>
            <name>G. Tyson</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>A. Molinaro</name>
        </author>
        <author>
            <name>S. Eum</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <abstract><p>This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.</p><p> This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-scenarios-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7476</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7477</doc-id>
        <title>Child-to-Parent Synchronization in DNS</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone.  The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.</p></abstract>
        <draft>draft-ietf-dnsop-child-syncronization-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7477</errata-url>
        <doi>10.17487/RFC7477</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7478</doc-id>
        <title>Web Real-Time Communication Use Cases and Requirements</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>S. Hakansson</name>
        </author>
        <author>
            <name>G. Eriksson</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>webrtc</kw>
            <kw>browser</kw>
            <kw>websocket</kw>
            <kw>real-time</kw>
        </keywords>
        <abstract><p>This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases.</p><p> This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.</p></abstract>
        <draft>draft-ietf-rtcweb-use-cases-and-requirements-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC7478</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7479</doc-id>
        <title>Using Ed25519 in SSHFP Resource Records</title>
        <author>
            <name>S. Moonesamy</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>The Ed25519 signature algorithm has been implemented in OpenSSH.  This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519.</p></abstract>
        <draft>draft-moonesamy-sshfp-ed25519-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7479</errata-url>
        <doi>10.17487/RFC7479</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7480</doc-id>
        <title>HTTP Usage in the Registration Data Access Protocol (RDAP)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>B. Ellacott</name>
        </author>
        <author>
            <name>N. Kong</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Registry</kw>
            <kw>WHOIS</kw>
        </keywords>
        <abstract><p>This document is one of a collection that together describes the Registration Data Access Protocol (RDAP).  It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP).  RDAP is a successor protocol to the very old WHOIS protocol.  The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.</p></abstract>
        <draft>draft-ietf-weirds-using-http-15</draft>
        <is-also>
            <doc-id>STD0095</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>weirds</wg_acronym>
        <doi>10.17487/RFC7480</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7481</doc-id>
        <title>Security Services for the Registration Data Access Protocol (RDAP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>N. Kong</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries.  This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.</p></abstract>
        <draft>draft-ietf-weirds-rdap-sec-12</draft>
        <is-also>
            <doc-id>STD0095</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>weirds</wg_acronym>
        <doi>10.17487/RFC7481</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7482</doc-id>
        <title>Registration Data Access Protocol (RDAP) Query Format</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>WHOIS</kw>
        </keywords>
        <abstract><p>This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns.  These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).</p></abstract>
        <draft>draft-ietf-weirds-rdap-query-18</draft>
        <obsoleted-by>
            <doc-id>RFC9082</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>weirds</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7482</errata-url>
        <doi>10.17487/RFC7482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7483</doc-id>
        <title>JSON Responses for the Registration Data Access Protocol (RDAP)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>78</page-count>
        <keywords>
            <kw>WHOIS</kw>
        </keywords>
        <abstract><p>This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs).  These data structures are used to form Registration Data Access Protocol (RDAP) query responses.</p></abstract>
        <draft>draft-ietf-weirds-json-response-14</draft>
        <obsoleted-by>
            <doc-id>RFC9083</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>weirds</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7483</errata-url>
        <doi>10.17487/RFC7483</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7484</doc-id>
        <title>Finding the Authoritative Registration Data (RDAP) Service</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>whois</kw>
            <kw>bootstrap</kw>
            <kw>IDN</kw>
            <kw>AS</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.</p></abstract>
        <draft>draft-ietf-weirds-bootstrap-11</draft>
        <obsoleted-by>
            <doc-id>RFC9224</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8521</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>weirds</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7484</errata-url>
        <doi>10.17487/RFC7484</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7485</doc-id>
        <title>Inventory and Analysis of WHOIS Registration Objects</title>
        <author>
            <name>L. Zhou</name>
        </author>
        <author>
            <name>N. Kong</name>
        </author>
        <author>
            <name>S. Shen</name>
        </author>
        <author>
            <name>S. Sheng</name>
        </author>
        <author>
            <name>A. Servin</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>whois</kw>
            <kw>restful</kw>
            <kw>weirds</kw>
            <kw>response object</kw>
            <kw>inventory</kw>
        </keywords>
        <abstract><p>WHOIS output objects from registries, including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed.  This document describes the process and results of the statistical analysis of existing WHOIS information.  The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses.</p></abstract>
        <draft>draft-ietf-weirds-object-inventory-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>weirds</wg_acronym>
        <doi>10.17487/RFC7485</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7486</doc-id>
        <title>HTTP Origin-Bound Authentication (HOBA)</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Network Working Group</kw>
            <kw>http authentication</kw>
            <kw>origin-bound key</kw>
        </keywords>
        <abstract><p>HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method.  The design can also be used in JavaScript-based authentication embedded in HTML.  HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.</p></abstract>
        <draft>draft-ietf-httpauth-hoba-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <doi>10.17487/RFC7486</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7487</doc-id>
        <title>Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE</title>
        <author>
            <name>E. Bellagamba</name>
        </author>
        <author>
            <name>A. Takacs</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>P. Skoldstrom</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>RSVP-TE</kw>
            <kw>GMPLS</kw>
            <kw>MPLS</kw>
            <kw>MPLS-TP</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This specification describes the configuration of proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.</p></abstract>
        <draft>draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7487</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7488</doc-id>
        <title>Port Control Protocol (PCP) Server Selection</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>P. Patil</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>PCP Server discovery</kw>
            <kw>Port Mapping</kw>
            <kw>Shared Address</kw>
            <kw>Multiple PCP Servers</kw>
        </keywords>
        <abstract><p>This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.</p><p> This document updates RFC 6887.</p></abstract>
        <draft>draft-ietf-pcp-server-selection-10</draft>
        <updates>
            <doc-id>RFC6887</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7488</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7489</doc-id>
        <title>Domain-based Message Authentication, Reporting, and Conformance (DMARC)</title>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Zwicky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>email</kw>
            <kw>security</kw>
            <kw>messaging</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>authentication</kw>
            <kw>reporting</kw>
            <kw>conformance</kw>
        </keywords>
        <abstract><p>Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.</p><p> Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.</p><p> DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.</p></abstract>
        <draft>draft-kucherawy-dmarc-base-12</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
            <doc-id>RFC8616</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7489</errata-url>
        <doi>10.17487/RFC7489</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7490</doc-id>
        <title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>N. So</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.</p></abstract>
        <draft>draft-ietf-rtgwg-remote-lfa-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC7490</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7491</doc-id>
        <title>A PCE-Based Architecture for Application-Based Network Operations</title>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>Software-Defined Networking (SDN)</kw>
            <kw>Path Computation Element (PCE)</kw>
            <kw>Network management</kw>
            <kw>Network programming</kw>
        </keywords>
        <abstract><p>Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.</p><p> This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.</p></abstract>
        <draft>draft-farrkingel-pce-abno-architecture-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7491</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7492</doc-id>
        <title>Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines</title>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>KARP</kw>
            <kw>replay attacks</kw>
            <kw>cryptographic authentication</kw>
            <kw>security</kw>
            <kw>DoS attacks</kw>
        </keywords>
        <abstract><p>This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".</p></abstract>
        <draft>draft-ietf-karp-bfd-analysis-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7492</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7493</doc-id>
        <title>The I-JSON Message Format</title>
        <author>
            <name>T. Bray</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>Internet JSON</kw>
        </keywords>
        <abstract><p>I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</p></abstract>
        <draft>draft-ietf-json-i-json-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>json</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7493</errata-url>
        <doi>10.17487/RFC7493</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7494</doc-id>
        <title>IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)</title>
        <author>
            <name>C. Shao</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <author>
            <name>F. Bari</name>
        </author>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>CAPWAP</kw>
            <kw>MAC Profile</kw>
            <kw>Encryption</kw>
            <kw>IEEE 802.11</kw>
        </keywords>
        <abstract><p>The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC.  In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined.  In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located.  This leads to interoperability issues, especially when the AC and WTP come from different vendors.  To prevent interoperability issues, this specification defines an IEEE 802.11 MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC.</p></abstract>
        <draft>draft-ietf-opsawg-capwap-hybridmac-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7494</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7495</doc-id>
        <title>Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)</title>
        <author>
            <name>A. Montville</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IODEF</kw>
            <kw>Incident</kw>
            <kw>Reference</kw>
            <kw>Enumeration</kw>
            <kw>Format</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.</p><p> This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.</p></abstract>
        <draft>draft-ietf-mile-enum-reference-format-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC7495</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7496</doc-id>
        <title>Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Seggelmann</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines two additional policies for the Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension.  These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-prpolicies-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC7496</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7497</doc-id>
        <title>Rate Measurement Test Protocol Problem Statement and Requirements</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet access</kw>
            <kw>Asymmetric Packet Size</kw>
        </keywords>
        <abstract><p>This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM).  Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.</p></abstract>
        <draft>draft-ietf-ippm-rate-problem-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7497</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7498</doc-id>
        <title>Problem Statement for Service Function Chaining</title>
        <author>
            <name>P. Quinn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>service function chaining</kw>
            <kw>steering</kw>
            <kw>sfc</kw>
        </keywords>
        <abstract><p>This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.</p><p> The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.</p><p> This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.</p></abstract>
        <draft>draft-ietf-sfc-problem-statement-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7498</errata-url>
        <doi>10.17487/RFC7498</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7499</doc-id>
        <title>Support of Fragmentation of RADIUS Packets</title>
        <author>
            <name>A. Perez-Mendez</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Marin-Lopez</name>
        </author>
        <author>
            <name>F. Pereniguez-Garcia</name>
        </author>
        <author>
            <name>G. Lopez-Millan</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>attribute</kw>
            <kw>extension</kw>
            <kw>fragmentation</kw>
            <kw>chunk</kw>
        </keywords>
        <abstract><p>The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes.  Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets.  No similar provisions exist for fragmenting large amounts of authorization data.  This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality.  These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.</p></abstract>
        <draft>draft-ietf-radext-radius-fragmentation-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC7499</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7500</doc-id>
        <title>Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries</title>
        <author>
            <name>R. Housley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.</p></abstract>
        <draft>draft-iab-iana-principles-05</draft>
        <obsoleted-by>
            <doc-id>RFC8720</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7500</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7501</doc-id>
        <title>Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration</title>
        <author>
            <name>C. Davids</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>S. Poretsky</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices.  Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502).  Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers.  The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages.  Media streams are used only to study how they impact the signaling behavior.  The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices.  Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.  A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.</p></abstract>
        <draft>draft-ietf-bmwg-sip-bench-term-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC7501</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7502</doc-id>
        <title>Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration</title>
        <author>
            <name>C. Davids</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>S. Poretsky</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices.  Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501).  Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers.  The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages.  Media streams are used only to study how they impact the signaling behavior.  The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices.  Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.</p></abstract>
        <draft>draft-ietf-bmwg-sip-bench-meth-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC7502</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7503</doc-id>
        <title>OSPFv3 Autoconfiguration</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement.  One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing.  This document describes the necessary mechanisms for OSPFv3 to be self-configuring.  This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-autoconfig-15</draft>
        <updates>
            <doc-id>RFC5340</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7503</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7504</doc-id>
        <title>SMTP 521 and 556 Reply Codes</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Reply code</kw>
            <kw>Email</kw>
            <kw>Server</kw>
            <kw>No Mail</kw>
        </keywords>
        <abstract><p>This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556.  The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP.  The 556 code was created to support the new tests and actions specified in RFC 7505.  These codes are used to indicate that an Internet host does not accept incoming mail at all.  This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.</p></abstract>
        <draft>draft-klensin-smtp-521code-07</draft>
        <updates>
            <doc-id>RFC1846</doc-id>
            <doc-id>RFC5321</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7504</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7505</doc-id>
        <title>A "Null MX" No Service Resource Record for Domains That Accept No Mail</title>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>M. Delany</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract><p>Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback.  Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail.  The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.</p></abstract>
        <draft>draft-ietf-appsawg-nullmx-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7505</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7506</doc-id>
        <title>IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)</title>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>LSP Ping</kw>
            <kw>MPLS OAM</kw>
        </keywords>
        <abstract><p>RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379.</p><p> The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute.</p></abstract>
        <draft>draft-ietf-mpls-oam-ipv6-rao-03</draft>
        <updates>
            <doc-id>RFC4379</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7506</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7507</doc-id>
        <title>TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks</title>
        <author>
            <name>B. Moeller</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.  It updates RFCs 2246, 4346, 4347, 5246, and 6347.  Server update considerations are included.</p></abstract>
        <draft>draft-ietf-tls-downgrade-scsv-05</draft>
        <obsoleted-by>
            <doc-id>RFC8996</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2246</doc-id>
            <doc-id>RFC4346</doc-id>
            <doc-id>RFC4347</doc-id>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC6347</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC7507</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7508</doc-id>
        <title>Securing Header Fields with S/MIME</title>
        <author>
            <name>L. Cailleux</name>
        </author>
        <author>
            <name>C. Bonatti</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>secure headers</kw>
        </keywords>
        <abstract><p>This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322.  This technology provides security services such as data integrity, non-repudiation, and confidentiality.  This extension is referred to as 'Secure Headers'.</p></abstract>
        <draft>draft-cailleux-secure-headers-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7508</errata-url>
        <doi>10.17487/RFC7508</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7509</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics</title>
        <author>
            <name>R. Huang</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications.  In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7509</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7510</doc-id>
        <title>Encapsulating MPLS in UDP</title>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>N. Sheth</name>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <author>
            <name>R. Callon</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>UDP</kw>
            <kw>Tunnel</kw>
            <kw>Checksum</kw>
            <kw>encapsulation</kw>
            <kw>multipath</kw>
            <kw>ECMP</kw>
        </keywords>
        <abstract><p>This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation.  The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required.  Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.</p></abstract>
        <draft>draft-ietf-mpls-in-udp-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7510</errata-url>
        <doi>10.17487/RFC7510</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7511</doc-id>
        <title>Scenic Routing for IPv6</title>
        <author>
            <name>M. Wilhelm</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>green it</kw>
        </keywords>
        <abstract><p>This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.</p></abstract>
        <draft>draft-scenig-routing</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7511</errata-url>
        <doi>10.17487/RFC7511</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7512</doc-id>
        <title>The PKCS #11 URI Scheme</title>
        <author>
            <name>J. Pechanec</name>
        </author>
        <author>
            <name>D. Moffat</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>PKCS11</kw>
            <kw>PKCS-11</kw>
            <kw>PKCS#11,</kw>
        </keywords>
        <abstract><p>This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries.  The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".</p></abstract>
        <draft>draft-pechanec-pkcs11uri-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7512</errata-url>
        <doi>10.17487/RFC7512</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7513</doc-id>
        <title>Source Address Validation Improvement (SAVI) Solution for DHCP</title>
        <author>
            <name>J. Bi</name>
        </author>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>G. Yao</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>SAVI-DHCP</kw>
        </keywords>
        <abstract><p>This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device.  The bindings set up by this procedure are used to filter packets with forged source IP addresses.  This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.</p></abstract>
        <draft>draft-ietf-savi-dhcp-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>savi</wg_acronym>
        <doi>10.17487/RFC7513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7514</doc-id>
        <title>Really Explicit Congestion Notification (RECN)</title>
        <author>
            <name>M. Luckie</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).</p></abstract>
        <draft>draft-luckie-recn</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7515</doc-id>
        <title>JSON Web Signature (JWS)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>N. Sakimura</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>JSON Web Algorithms</kw>
            <kw>JWA</kw>
        </keywords>
        <abstract><p>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</p></abstract>
        <draft>draft-ietf-jose-json-web-signature-41</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7515</errata-url>
        <doi>10.17487/RFC7515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7516</doc-id>
        <title>JSON Web Encryption (JWE)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Hildebrand</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>JSON Web Algorithms</kw>
            <kw>JWA</kw>
        </keywords>
        <abstract><p>JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification.  Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.</p></abstract>
        <draft>draft-ietf-jose-json-web-encryption-40</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7516</errata-url>
        <doi>10.17487/RFC7516</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7517</doc-id>
        <title>JSON Web Key (JWK)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>JSON Web Algorithms</kw>
            <kw>JWA</kw>
        </keywords>
        <abstract><p>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JWK Set JSON data structure that represents a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</p></abstract>
        <draft>draft-ietf-jose-json-web-key-41</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7517</errata-url>
        <doi>10.17487/RFC7517</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7518</doc-id>
        <title>JSON Web Algorithms (JWA)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <abstract><p>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</p></abstract>
        <draft>draft-ietf-jose-json-web-algorithms-40</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7518</errata-url>
        <doi>10.17487/RFC7518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7519</doc-id>
        <title>JSON Web Token (JWT)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>N. Sakimura</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Assertion</kw>
            <kw>Claim</kw>
            <kw>Security Token</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>JSON Web Algorithms</kw>
            <kw>JWA</kw>
        </keywords>
        <abstract><p>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</p></abstract>
        <draft>draft-ietf-oauth-json-web-token-32</draft>
        <updated-by>
            <doc-id>RFC7797</doc-id>
            <doc-id>RFC8725</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7519</errata-url>
        <doi>10.17487/RFC7519</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7520</doc-id>
        <title>Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)</title>
        <author>
            <name>M. Miller</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>120</page-count>
        <keywords>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>JSON Web Algorithms</kw>
            <kw>JWA</kw>
            <kw>Cookbook</kw>
        </keywords>
        <abstract><p>This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data.  These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs.</p></abstract>
        <draft>draft-ietf-jose-cookbook-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7520</errata-url>
        <doi>10.17487/RFC7520</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7521</doc-id>
        <title>Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>C. Mortimore</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>Y. Goland</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>SAML</kw>
            <kw>JWT</kw>
            <kw>Assertion</kw>
        </keywords>
        <abstract><p>This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.</p><p> The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.</p><p> Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.</p></abstract>
        <draft>draft-ietf-oauth-assertions-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC7521</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7522</doc-id>
        <title>Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>C. Mortimore</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>SAML</kw>
            <kw>Assertion</kw>
        </keywords>
        <abstract><p>This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.</p></abstract>
        <draft>draft-ietf-oauth-saml2-bearer-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC7522</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7523</doc-id>
        <title>JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>C. Mortimore</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>JWT</kw>
            <kw>Assertion</kw>
            <kw>Token</kw>
            <kw>Security Token</kw>
        </keywords>
        <abstract><p>This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.</p></abstract>
        <draft>draft-ietf-oauth-jwt-bearer-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC7523</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7524</doc-id>
        <title>Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>T. Morin</name>
        </author>
        <author>
            <name>I. Grosclaude</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>S. Saad</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP).  Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication.  The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP).  If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area.  The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.</p></abstract>
        <draft>draft-ietf-mpls-seamless-mcast-17</draft>
        <updated-by>
            <doc-id>RFC8534</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7524</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7525</doc-id>
        <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>R. Holz</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Transport Layer Security</kw>
            <kw>TLS</kw>
            <kw>DTLS</kw>
            <kw>Secure Sockets Layer</kw>
            <kw>SSL</kw>
        </keywords>
        <abstract><p>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS.  The recommendations are applicable to the majority of use cases.</p></abstract>
        <draft>draft-ietf-uta-tls-bcp-11</draft>
        <obsoleted-by>
            <doc-id>RFC9325</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7525</errata-url>
        <doi>10.17487/RFC7525</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7526</doc-id>
        <title>Deprecating the Anycast Prefix for 6to4 Relay Routers</title>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode.  Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status.  It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed.  This complements the guidelines in RFC 6343.</p></abstract>
        <draft>draft-ietf-v6ops-6to4-to-historic-11</draft>
        <obsoletes>
            <doc-id>RFC3068</doc-id>
            <doc-id>RFC6732</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0196</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7527</doc-id>
        <title>Enhanced Duplicate Address Detection</title>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>H. Singh</name>
        </author>
        <author>
            <name>W. Beebee</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>E. Dart</name>
        </author>
        <author>
            <name>W. George</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Automated DAD</kw>
            <kw>loopback detection</kw>
        </keywords>
        <abstract><p>IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862.  That specification mentions a hardware-assisted mechanism to detect looped back DAD messages.  If hardware cannot suppress looped back DAD messages, a software solution is required.  Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD.  This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD.  For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed.  Further, for certain access networks, this document automates resolving a specific duplicate address conflict.  This document updates RFCs 4429, 4861, and 4862.</p></abstract>
        <draft>draft-ietf-6man-enhanced-dad-15</draft>
        <updates>
            <doc-id>RFC4429</doc-id>
            <doc-id>RFC4861</doc-id>
            <doc-id>RFC4862</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7527</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7528</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association</title>
        <author>
            <name>P. Higgs</name>
        </author>
        <author>
            <name>J. Piesing</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications.  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 HbbTV.</p></abstract>
        <draft>draft-higgs-hbbtv-urn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7528</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7529</doc-id>
        <title>Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>G. Yakushev</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>calendaring</kw>
            <kw>iCalendar</kw>
            <kw>iTIP</kw>
            <kw>CalDAV</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules.  It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.</p></abstract>
        <draft>draft-ietf-calext-rscale-04</draft>
        <updates>
            <doc-id>RFC5545</doc-id>
            <doc-id>RFC6321</doc-id>
            <doc-id>RFC7265</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>calext</wg_acronym>
        <doi>10.17487/RFC7529</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7530</doc-id>
        <title>Network File System (NFS) Version 4 Protocol</title>
        <author>
            <name>T. Haynes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Noveck</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>323</page-count>
        <abstract><p>The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of 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 has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.</p><p> This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.</p></abstract>
        <draft>draft-ietf-nfsv4-rfc3530bis-35</draft>
        <obsoletes>
            <doc-id>RFC3530</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC7931</doc-id>
            <doc-id>RFC8587</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7530</errata-url>
        <doi>10.17487/RFC7530</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7531</doc-id>
        <title>Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description</title>
        <author>
            <name>T. Haynes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Noveck</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its 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 has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.</p><p> RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.</p></abstract>
        <draft>draft-ietf-nfsv4-rfc3530bis-dot-x-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7531</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7532</doc-id>
        <title>Namespace Database (NSDB) Protocol for Federated File Systems</title>
        <author>
            <name>J. Lentini</name>
        </author>
        <author>
            <name>R. Tewari</name>
        </author>
        <author>
            <name>C. Lever</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>Federated File Systems</kw>
        </keywords>
        <abstract><p>This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers.  The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.</p></abstract>
        <draft>draft-ietf-nfsv4-federated-fs-protocol-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7532</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7533</doc-id>
        <title>Administration Protocol for Federated File Systems</title>
        <author>
            <name>J. Lentini</name>
        </author>
        <author>
            <name>R. Tewari</name>
        </author>
        <author>
            <name>C. Lever</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Federated File Systems</kw>
        </keywords>
        <abstract><p>This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers.  The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.</p></abstract>
        <draft>draft-ietf-nfsv4-federated-fs-admin-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7533</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7534</doc-id>
        <title>AS112 Nameserver Operations</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>W. Sotomayor</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>AS112</kw>
            <kw>DNS</kw>
            <kw>reverse DNS</kw>
            <kw>anycast</kw>
        </keywords>
        <abstract><p>Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.</p><p> Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.</p><p> It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.</p><p> This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.</p><p> This document obsoletes RFC 6304.</p></abstract>
        <draft>draft-ietf-dnsop-rfc6304bis-06</draft>
        <obsoletes>
            <doc-id>RFC6304</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7534</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7535</doc-id>
        <title>AS112 Redirection Using DNAME</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>B. Dickson</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>root server</kw>
        </keywords>
        <abstract><p>AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.</p><p> This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.</p></abstract>
        <draft>draft-ietf-dnsop-as112-dname-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7535</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7536</doc-id>
        <title>Large-Scale Broadband Measurement Use Cases</title>
        <author>
            <name>M. Linsner</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>T. Burbridge</name>
        </author>
        <author>
            <name>F. Sorensen</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>lmap</kw>
        </keywords>
        <abstract><p>Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy.  Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol.  This document details two use cases that can assist in developing that framework.  The details of the measurement metrics themselves are beyond the scope of this document.</p></abstract>
        <draft>draft-ietf-lmap-use-cases-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lmap</wg_acronym>
        <doi>10.17487/RFC7536</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7537</doc-id>
        <title>IANA Registries for LSP Ping Code Points</title>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>MPLS OAM</kw>
            <kw>lsp ping</kw>
            <kw>LSP-Ping</kw>
        </keywords>
        <abstract><p>RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types.</p><p> There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-registry-03</draft>
        <obsoleted-by>
            <doc-id>RFC8029</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4379</doc-id>
            <doc-id>RFC6424</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7537</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7538</doc-id>
        <title>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>April</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>redirect</kw>
            <kw>status code</kw>
        </keywords>
        <abstract><p>This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).</p></abstract>
        <draft>draft-ietf-httpbis-rfc7238bis-03</draft>
        <obsoletes>
            <doc-id>RFC7238</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC7538</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7539</doc-id>
        <title>ChaCha20 and Poly1305 for IETF Protocols</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>AEAD</kw>
        </keywords>
        <abstract><p>This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</p><p> This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).</p></abstract>
        <draft>draft-irtf-cfrg-chacha20-poly1305-10</draft>
        <obsoleted-by>
            <doc-id>RFC8439</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7539</errata-url>
        <doi>10.17487/RFC7539</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7540</doc-id>
        <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
        <author>
            <name>M. Belshe</name>
        </author>
        <author>
            <name>R. Peon</name>
        </author>
        <author>
            <name>M. Thomson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>SPDY</kw>
            <kw>Web</kw>
        </keywords>
        <abstract><p>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.</p><p> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.</p></abstract>
        <draft>draft-ietf-httpbis-http2-17</draft>
        <obsoleted-by>
            <doc-id>RFC9113</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC8740</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7540</errata-url>
        <doi>10.17487/RFC7540</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7541</doc-id>
        <title>HPACK: Header Compression for HTTP/2</title>
        <author>
            <name>R. Peon</name>
        </author>
        <author>
            <name>H. Ruellan</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>Header</kw>
        </keywords>
        <abstract><p>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</p></abstract>
        <draft>draft-ietf-httpbis-header-compression-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7541</errata-url>
        <doi>10.17487/RFC7541</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7542</doc-id>
        <title>The Network Access Identifier</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users.  This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources.  This document is a revised version of RFC 4282.  It addresses issues with international character sets and makes a number of other corrections to RFC 4282.</p></abstract>
        <draft>draft-ietf-radext-nai-15</draft>
        <obsoletes>
            <doc-id>RFC4282</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7542</errata-url>
        <doi>10.17487/RFC7542</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7543</doc-id>
        <title>Covering Prefixes Outbound Route Filter for BGP-4</title>
        <author>
            <name>H. Jeng</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>ORF</kw>
            <kw>VPN</kw>
        </keywords>
        <abstract><p>This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF).  CP-ORF is applicable in Virtual Hub-and-Spoke VPNs.  It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.</p></abstract>
        <draft>draft-ietf-bess-orf-covering-prefixes-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7543</errata-url>
        <doi>10.17487/RFC7543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7544</doc-id>
        <title>Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>M. Mohali</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Diversion</kw>
            <kw>History-Info</kw>
        </keywords>
        <abstract><p>Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.</p><p> RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.</p><p> Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.</p><p> This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.</p></abstract>
        <draft>draft-mohali-rfc6044bis-02</draft>
        <obsoletes>
            <doc-id>RFC6044</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7544</errata-url>
        <doi>10.17487/RFC7544</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7545</doc-id>
        <title>Protocol to Access White-Space (PAWS) Databases</title>
        <author>
            <name>V. Chen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Das</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>J. Malyar</name>
        </author>
        <author>
            <name>P. McCann</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>dynamic spectrum</kw>
            <kw>radio spectrum</kw>
            <kw>wireless spectrum</kw>
            <kw>spectrum</kw>
            <kw>spectrum database</kw>
            <kw>TV white space</kw>
            <kw>TVWS</kw>
            <kw>TVBD</kw>
            <kw>white space device</kw>
            <kw>WSD</kw>
        </keywords>
        <abstract><p>Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "white space". Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.</p><p> One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White-Space (PAWS) Databases".</p></abstract>
        <draft>draft-ietf-paws-protocol-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>paws</wg_acronym>
        <doi>10.17487/RFC7545</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7546</doc-id>
        <title>Structure of the Generic Security Service (GSS) Negotiation Loop</title>
        <author>
            <name>B. Kaduk</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor.  The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.</p></abstract>
        <draft>draft-ietf-kitten-gss-loop-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC7546</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7547</doc-id>
        <title>Management of Networks with Constrained Devices: Problem Statement and Requirements</title>
        <author>
            <name>M. Ersue</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>U. Herberg</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Constrained</kw>
            <kw>Management</kw>
            <kw>IoT</kw>
            <kw>M2M</kw>
        </keywords>
        <abstract><p>This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.</p></abstract>
        <draft>draft-ietf-opsawg-coman-probstate-reqs-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7547</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7548</doc-id>
        <title>Management of Networks with Constrained Devices: Use Cases</title>
        <author>
            <name>M. Ersue</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>A. Sehgal</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Constrained</kw>
            <kw>Management</kw>
            <kw>IoT</kw>
            <kw>M2M</kw>
        </keywords>
        <abstract><p>This document discusses use cases concerning the management of networks in which constrained devices are involved.  A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547).</p></abstract>
        <draft>draft-ietf-opsawg-coman-use-cases-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7548</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7549</doc-id>
        <title>3GPP SIP URI Inter-Operator Traffic Leg Parameter</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>J. Holm</name>
        </author>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>M. Dolly</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>3GPP</kw>
            <kw>IMS</kw>
            <kw>NNI</kw>
            <kw>IOTL</kw>
            <kw>CSCF</kw>
            <kw>RAVEL</kw>
            <kw>TRF</kw>
            <kw>operator</kw>
            <kw>transit</kw>
        </keywords>
        <abstract><p>In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.</p><p> This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).</p></abstract>
        <draft>draft-holmberg-dispatch-iotl-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7549</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7550</doc-id>
        <title>Issues and Recommendations with Multiple Stateful DHCPv6 Options</title>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>M. Siodelski</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>CPE</kw>
            <kw>CER</kw>
            <kw>CE</kw>
            <kw>Customer Edge Router</kw>
            <kw>Prefix Delegation</kw>
            <kw>IPv6 Address Option</kw>
            <kw>Session</kw>
            <kw>State Machine</kw>
            <kw>Advertise</kw>
            <kw>Time</kw>
            <kw>Timer T1 T2</kw>
            <kw>Renew</kw>
            <kw>Rebind</kw>
            <kw>Confirm</kw>
            <kw>Decline</kw>
            <kw>Provision</kw>
        </keywords>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options.  DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.  Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed.  This document updates RFCs 3315 and 3633 to address these issues.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-stateful-issues-12</draft>
        <obsoleted-by>
            <doc-id>RFC8415</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3315</doc-id>
            <doc-id>RFC3633</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7551</doc-id>
        <title>RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title>
        <author>
            <name>F. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Jing</name>
        </author>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP.  The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects.  One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning.  The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.</p></abstract>
        <draft>draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07</draft>
        <updated-by>
            <doc-id>RFC8537</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7551</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7552</doc-id>
        <title>Updates to LDP for IPv6</title>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>R. Papneja</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Label Distribution Protocol</kw>
        </keywords>
        <abstract><p>The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both.  This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4).  This document updates RFCs 5036 and 6720.</p></abstract>
        <draft>draft-ietf-mpls-ldp-ipv6-17</draft>
        <updates>
            <doc-id>RFC5036</doc-id>
            <doc-id>RFC6720</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7552</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7553</doc-id>
        <title>The Uniform Resource Identifier (URI) DNS Resource Record</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>O. Kolkman</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Operations</kw>
            <kw>DNS</kw>
            <kw>applications</kw>
        </keywords>
        <abstract><p>This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.</p></abstract>
        <draft>draft-faltstrom-uri-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7553</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7554</doc-id>
        <title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement</title>
        <author>
            <name>T. Watteyne</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Palattella</name>
        </author>
        <author>
            <name>L. Grieco</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>6TiSCH</kw>
        </keywords>
        <abstract><p>This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs).  The set of goals enumerated in this document form an initial set only.</p></abstract>
        <draft>draft-ietf-6tisch-tsch-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7554</errata-url>
        <doi>10.17487/RFC7554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7555</doc-id>
        <title>Proxy MPLS Echo Request</title>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>V. Lim</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths.  An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path.  The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).</p></abstract>
        <draft>draft-ietf-mpls-proxy-lsp-ping-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7555</errata-url>
        <doi>10.17487/RFC7555</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7556</doc-id>
        <title>Multiple Provisioning Domain Architecture</title>
        <author>
            <name>D. Anipko</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</p></abstract>
        <draft>draft-ietf-mif-mpvd-arch-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mif</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7556</errata-url>
        <doi>10.17487/RFC7556</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7557</doc-id>
        <title>Extension Mechanism for the Babel Routing Protocol</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Babel</kw>
            <kw>routing</kw>
            <kw>extension</kw>
            <kw>TLV</kw>
            <kw>sub-TLV</kw>
        </keywords>
        <abstract><p>This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.</p></abstract>
        <draft>draft-chroboczek-babel-extension-mechanism-04</draft>
        <obsoleted-by>
            <doc-id>RFC8966</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6126</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7557</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7558</doc-id>
        <title>Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions</title>
        <author>
            <name>K. Lynn</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link.  This document provides a problem statement and a list of requirements for scalable DNS-SD.</p></abstract>
        <draft>draft-ietf-dnssd-requirements-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC7558</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7559</doc-id>
        <title>Packet-Loss Resiliency for Router Solicitations</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>D. Anipko</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received.  In certain scenarios, these Router Solicitations transmitted by the host might be lost.  This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.</p></abstract>
        <draft>draft-ietf-6man-resilient-rs-06</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7559</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7560</doc-id>
        <title>Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback</title>
        <author>
            <name>M. Kuehlewind</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Scheffenegger</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>congestion control</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints.  An ECN-capable receiver will feed this information back to the sender.  ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT).  In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback.  Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT.  This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.</p></abstract>
        <draft>draft-ietf-tcpm-accecn-reqs-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC7560</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7561</doc-id>
        <title>Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN</title>
        <author>
            <name>J. Kaippallimalil</name>
        </author>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <author>
            <name>P. Yegani</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>PMIPv6</kw>
            <kw>Wi-Fi</kw>
            <kw>QoS</kw>
        </keywords>
        <abstract><p>This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11.  RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain.  The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA.  IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point.  This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters.  This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.</p></abstract>
        <draft>draft-ietf-netext-pmip-qos-wifi-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7561</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7562</doc-id>
        <title>Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates</title>
        <author>
            <name>D. Thakore</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Transport Layer Security</kw>
            <kw>TLS</kw>
            <kw>SupplementalData</kw>
            <kw>DTCP</kw>
        </keywords>
        <abstract><p>This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol.  This is in accordance with the guidelines for authorization extensions as specified in RFC 5878.  As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types.  If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680.  This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).</p></abstract>
        <draft>draft-dthakore-tls-authz-08</draft>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7562</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7563</doc-id>
        <title>Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option</title>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <author>
            <name>S. Speicher</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>J. Kaippallimalil</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6".  This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier.  This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier.  This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.</p></abstract>
        <draft>draft-ietf-netext-ani-location-09</draft>
        <updates>
            <doc-id>RFC6757</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7563</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7564</doc-id>
        <title>PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>internationalization</kw>
            <kw>i18n</kw>
            <kw>Stringprep</kw>
        </keywords>
        <abstract><p>Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization).  This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode.  As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  This document obsoletes RFC 3454.</p></abstract>
        <draft>draft-ietf-precis-framework-23</draft>
        <obsoletes>
            <doc-id>RFC3454</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8264</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>precis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7564</errata-url>
        <doi>10.17487/RFC7564</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7565</doc-id>
        <title>The 'acct' URI Scheme</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>May</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Uniform Resource Identifier</kw>
            <kw>URI</kw>
        </keywords>
        <abstract><p>This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.</p></abstract>
        <draft>draft-ietf-appsawg-acct-uri-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>app</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7565</errata-url>
        <doi>10.17487/RFC7565</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7566</doc-id>
        <title>Enumservice Registration for 'acct' URI</title>
        <author>
            <name>L. Goix</name>
        </author>
        <author>
            <name>K. Li</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Reverse Phone Lookup</kw>
            <kw>Social Network Web</kw>
        </keywords>
        <abstract><p>This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).</p></abstract>
        <draft>draft-goix-appsawg-enum-acct-uri-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7566</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7567</doc-id>
        <title>IETF Recommendations Regarding Active Queue Management</title>
        <author>
            <name>F. Baker</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Fairhurst</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>This memo presents 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 (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.</p><p> Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.</p></abstract>
        <draft>draft-ietf-aqm-recommendation-11</draft>
        <obsoletes>
            <doc-id>RFC2309</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0197</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7567</errata-url>
        <doi>10.17487/RFC7567</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7568</doc-id>
        <title>Deprecating Secure Sockets Layer Version 3.0</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>A. Pironti</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>SSL</kw>
            <kw>TLS</kw>
            <kw>insecure</kw>
            <kw>diediedie</kw>
        </keywords>
        <abstract><p>The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.</p><p> This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.</p></abstract>
        <draft>draft-ietf-tls-sslv3-diediedie-03</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7568</errata-url>
        <doi>10.17487/RFC7568</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7569</doc-id>
        <title>Registry Specification for Mandatory Access Control (MAC) Security Label Formats</title>
        <author>
            <name>D. Quigley</name>
        </author>
        <author>
            <name>J. Lu</name>
        </author>
        <author>
            <name>T. Haynes</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.</p><p> To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.</p></abstract>
        <draft>draft-ietf-nfsv4-lfs-registry-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7569</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7570</doc-id>
        <title>Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)</title>
        <author>
            <name>C. Margaria</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Martinelli</name>
        </author>
        <author>
            <name>S. Balls</name>
        </author>
        <author>
            <name>B. Wright</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>RSVP-TE</kw>
            <kw>GMPLS</kw>
        </keywords>
        <abstract><p>RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP).  This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.</p></abstract>
        <draft>draft-ietf-teas-lsp-attribute-ro-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7571</doc-id>
        <title>GMPLS RSVP-TE Extensions for Lock Instruct and Loopback</title>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs).  These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.</p></abstract>
        <draft>draft-ietf-teas-rsvp-te-li-lb-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7571</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7572</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>A. Houri</name>
        </author>
        <author>
            <name>J. Hildebrand</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>SIP</kw>
            <kw>SIMPLE</kw>
            <kw>IM</kw>
            <kw>Instant Message</kw>
        </keywords>
        <abstract><p>This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).</p></abstract>
        <draft>draft-ietf-stox-im-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stox</wg_acronym>
        <doi>10.17487/RFC7572</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7573</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Text Chat</kw>
            <kw>Instant Messaging</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>SIP</kw>
            <kw>Message Sessions Relay Protocol</kw>
            <kw>MSRP</kw>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>XMPP</kw>
        </keywords>
        <abstract><p>This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP).  Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).</p></abstract>
        <draft>draft-ietf-stox-chat-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stox</wg_acronym>
        <doi>10.17487/RFC7573</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7574</doc-id>
        <title>Peer-to-Peer Streaming Peer Protocol (PPSPP)</title>
        <author>
            <name>A. Bakker</name>
        </author>
        <author>
            <name>R. Petrocco</name>
        </author>
        <author>
            <name>V. Grishchenko</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>video on demand</kw>
            <kw>live streaming</kw>
            <kw>content integrity protection</kw>
        </keywords>
        <abstract><p>The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion.  PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content.  It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth.  It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers.  PPSPP has also been designed to be flexible and extensible.  It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables).  It supports multiple methods for content integrity protection and chunk addressing.  Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.</p></abstract>
        <draft>draft-ietf-ppsp-peer-protocol-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ppsp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7574</errata-url>
        <doi>10.17487/RFC7574</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7575</doc-id>
        <title>Autonomic Networking: Definitions and Design Goals</title>
        <author>
            <name>M. Behringer</name>
        </author>
        <author>
            <name>M. Pritikin</name>
        </author>
        <author>
            <name>S. Bjarnason</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>L. Ciavaglia</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>self-management</kw>
            <kw>self-chop</kw>
            <kw>autonomic</kw>
            <kw>secure by default</kw>
            <kw>simplification</kw>
        </keywords>
        <abstract><p>Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.</p><p> This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.</p></abstract>
        <draft>draft-irtf-nmrg-autonomic-network-definitions-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7575</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7576</doc-id>
        <title>General Gap Analysis for Autonomic Networking</title>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>M. Behringer</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.</p><p> This document is a product of the IRTF's Network Management Research Group.</p></abstract>
        <draft>draft-irtf-nmrg-an-gap-analysis-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7577</doc-id>
        <title>Definition of Managed Objects for Battery Monitoring</title>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>T. Dietz</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Energy Management</kw>
            <kw>Battery Status</kw>
            <kw>Battery MIB</kw>
            <kw>Management Information Base</kw>
        </keywords>
        <abstract><p>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 managed objects that provide information on the status of batteries in managed devices.</p></abstract>
        <draft>draft-ietf-eman-battery-mib-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <doi>10.17487/RFC7577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7578</doc-id>
        <title>Returning Values from Forms: multipart/form-data</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>media-type</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract><p>This specification defines the multipart/form-data media type, 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.  This document obsoletes RFC 2388.</p></abstract>
        <draft>draft-ietf-appsawg-multipart-form-data-11</draft>
        <obsoletes>
            <doc-id>RFC2388</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7578</errata-url>
        <doi>10.17487/RFC7578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7579</doc-id>
        <title>General Network Element Constraint Encoding for GMPLS-Controlled Networks</title>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>W. Imajuku</name>
        </author>
        <author>
            <name>J. Han</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>WSON</kw>
            <kw>Optical Network Control</kw>
            <kw>Protocol-agnostic encoding</kw>
        </keywords>
        <abstract><p>Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.</p><p> This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.</p></abstract>
        <draft>draft-ietf-ccamp-general-constraint-encode-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7580</doc-id>
        <title>OSPF-TE Extensions for General Network Element Constraints</title>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>J. Han</name>
        </author>
        <author>
            <name>G. Bernstein</name>
        </author>
        <author>
            <name>Y. Xu</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>WSON</kw>
            <kw>Optical Routing</kw>
        </keywords>
        <abstract><p>Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).  In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links.  This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7580</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7581</doc-id>
        <title>Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks</title>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <author>
            <name>W. Imajuku</name>
        </author>
        <author>
            <name>J. Han</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Optical Networks</kw>
            <kw>GMPLS control plane</kw>
            <kw>Wavelength Assignment</kw>
            <kw>Optical LSP</kw>
            <kw>Optical Routing</kw>
        </keywords>
        <abstract><p>A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.</p><p> This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).</p></abstract>
        <draft>draft-ietf-ccamp-rwa-wson-encode-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7581</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7582</doc-id>
        <title>Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>A. Boers</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs.  These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels.  The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute.  Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees.  However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs.  This document updates RFCs 6513, 6514, and 6625 by specifying those procedures.  In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.</p></abstract>
        <draft>draft-ietf-bess-mvpn-bidir-04</draft>
        <updates>
            <doc-id>RFC6513</doc-id>
            <doc-id>RFC6514</doc-id>
            <doc-id>RFC6625</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8534</doc-id>
            <doc-id>RFC9573</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7582</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7583</doc-id>
        <title>DNSSEC Key Rollover Timing Considerations</title>
        <author>
            <name>S. Morris</name>
        </author>
        <author>
            <name>J. Ihren</name>
        </author>
        <author>
            <name>J. Dickinson</name>
        </author>
        <author>
            <name>W. Mekking</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone.  It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-key-timing-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7583</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7584</doc-id>
        <title>Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)</title>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.</p><p> This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.</p></abstract>
        <draft>draft-ietf-straw-b2bua-stun-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>straw</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7584</errata-url>
        <doi>10.17487/RFC7584</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7585</doc-id>
        <title>Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)</title>
        <author>
            <name>S. Winter</name>
        </author>
        <author>
            <name>M. McCauley</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>AAA</kw>
            <kw>Security</kw>
            <kw>Reliability</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document specifies a means to find authoritative RADIUS servers for a given realm.  It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).</p></abstract>
        <draft>draft-ietf-radext-dynamic-discovery-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7585</errata-url>
        <doi>10.17487/RFC7585</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7586</doc-id>
        <title>The Scalable Address Resolution Protocol (SARP) for Large Data Centers</title>
        <author>
            <name>Y. Nachum</name>
        </author>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>I. Yerushalmi</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>ARP</kw>
            <kw>data center</kw>
            <kw>proxy</kw>
        </keywords>
        <abstract><p>This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks.  SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations.  SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.</p></abstract>
        <draft>draft-nachum-sarp-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7586</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7587</doc-id>
        <title>RTP Payload Format for the Opus Speech and Audio Codec</title>
        <author>
            <name>J. Spittka</name>
        </author>
        <author>
            <name>K. Vos</name>
        </author>
        <author>
            <name>JM. Valin</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>audio codec</kw>
        </keywords>
        <abstract><p>This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way.  It also provides an applicability statement for the use of Opus over RTP.  Further, it describes media type registrations for the RTP payload format.</p></abstract>
        <draft>draft-ietf-payload-rtp-opus-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC7587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7588</doc-id>
        <title>A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>GRE</kw>
            <kw>MTU</kw>
            <kw>Fragmentation</kw>
        </keywords>
        <abstract><p>This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem.  The solution described herein is configurable.  It is widely deployed on the Internet in its default configuration.</p></abstract>
        <draft>draft-ietf-intarea-gre-mtu-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC7588</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7589</doc-id>
        <title>Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title>
        <author>
            <name>M. Badra</name>
        </author>
        <author>
            <name>A. Luchuk</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.  This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages.  This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.</p></abstract>
        <draft>draft-ietf-netconf-rfc5539bis-10</draft>
        <obsoletes>
            <doc-id>RFC5539</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7589</errata-url>
        <doi>10.17487/RFC7589</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7590</doc-id>
        <title>Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>T. Alkemade</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>Secure Sockets Layer</kw>
            <kw>SSL</kw>
            <kw>Transport Layer Security</kw>
            <kw>TLS</kw>
            <kw>instant messaging</kw>
            <kw>presence</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP).  This document updates RFC 6120.</p></abstract>
        <draft>draft-ietf-uta-xmpp-07</draft>
        <updates>
            <doc-id>RFC6120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <doi>10.17487/RFC7590</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7591</doc-id>
        <title>OAuth 2.0 Dynamic Client Registration Protocol</title>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>M. Machulak</name>
        </author>
        <author>
            <name>P. Hunt</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>OpenID Connect Dynamic Client Registration</kw>
            <kw>OpenID Connect</kw>
            <kw>oidc</kw>
            <kw>openid</kw>
            <kw>user managed access</kw>
            <kw>uma</kw>
            <kw>Dynamic Registration</kw>
            <kw>Dynamic Client Registration</kw>
        </keywords>
        <abstract><p>This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers.  Registration requests send a set of desired client metadata values to the authorization server.  The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client.  The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol.  This specification also defines a set of common client metadata fields and values for clients to use during registration.</p></abstract>
        <draft>draft-ietf-oauth-dyn-reg-30</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7591</errata-url>
        <doi>10.17487/RFC7591</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7592</doc-id>
        <title>OAuth 2.0 Dynamic Client Registration Management Protocol</title>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>M. Machulak</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client.  Not all authorization servers supporting dynamic client registration will support these management methods.</p></abstract>
        <draft>draft-ietf-oauth-dyn-reg-management-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC7592</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7593</doc-id>
        <title>The eduroam Architecture for Network Roaming</title>
        <author>
            <name>K. Wierenga</name>
        </author>
        <author>
            <name>S. Winter</name>
        </author>
        <author>
            <name>T. Wolniewicz</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Federated Authentication</kw>
            <kw>AAA</kw>
            <kw>RADIUS</kw>
            <kw>IEEE 802.1X</kw>
            <kw>roaming</kw>
            <kw>EAP</kw>
            <kw>eduroam</kw>
        </keywords>
        <abstract><p>This document describes the architecture of the eduroam service for federated (wireless) network access in academia.  The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access.  The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document.  In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.</p></abstract>
        <draft>draft-wierenga-ietf-eduroam-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7593</errata-url>
        <doi>10.17487/RFC7593</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7594</doc-id>
        <title>A Framework for Large-Scale Measurement of Broadband Performance (LMAP)</title>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>T. Burbridge</name>
        </author>
        <author>
            <name>P. Aitken</name>
        </author>
        <author>
            <name>A. Akhter</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>Controller</kw>
            <kw>Collector</kw>
            <kw>Measurement Agent</kw>
            <kw>Metric</kw>
            <kw>Measurement Method</kw>
            <kw>Measurement Results</kw>
            <kw>Registry</kw>
        </keywords>
        <abstract><p>Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components.  This document presents an overall framework for large-scale measurements.  It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance).</p></abstract>
        <draft>draft-ietf-lmap-framework-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lmap</wg_acronym>
        <doi>10.17487/RFC7594</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7595</doc-id>
        <title>Guidelines and Registration Procedures for URI Schemes</title>
        <author>
            <name>D. Thaler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Hansen</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>URI scheme</kw>
            <kw>IRI</kw>
            <kw>Internationalized Resource Identifier</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>URI registration</kw>
        </keywords>
        <abstract><p>This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes.  It obsoletes RFC 4395.</p></abstract>
        <draft>draft-ietf-appsawg-uri-scheme-reg-06</draft>
        <obsoletes>
            <doc-id>RFC4395</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8615</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0035</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7595</errata-url>
        <doi>10.17487/RFC7595</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7596</doc-id>
        <title>Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture</title>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>DS-Lite</kw>
            <kw>address sharing</kw>
            <kw>address exhaustion</kw>
            <kw>aplusp</kw>
            <kw>A+P</kw>
            <kw>IPv4 service continuity</kw>
            <kw>IPv4 over IPv6 connectivity</kw>
        </keywords>
        <abstract><p>Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network.  This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE).  This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level.  In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.</p></abstract>
        <draft>draft-ietf-softwire-lw4over6-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC7596</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7597</doc-id>
        <title>Mapping of Address and Port with Encapsulation (MAP-E)</title>
        <author>
            <name>O. Troan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Dec</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>T. Murakami</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation.  It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.</p></abstract>
        <draft>draft-ietf-softwire-map-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC7597</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7598</doc-id>
        <title>DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients</title>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>S. Perreault</name>
        </author>
        <author>
            <name>W. Dec</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>L. Yeh</name>
        </author>
        <author>
            <name>X. Deng</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>MAP</kw>
            <kw>DHCPv6</kw>
        </keywords>
        <abstract><p>This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices.  Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.</p></abstract>
        <draft>draft-ietf-softwire-map-dhcp-12</draft>
        <updated-by>
            <doc-id>RFC8539</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7598</errata-url>
        <doi>10.17487/RFC7598</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7599</doc-id>
        <title>Mapping of Address and Port using Translation (MAP-T)</title>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>W. Dec</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>T. Murakami</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.</p></abstract>
        <draft>draft-ietf-softwire-map-t-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7599</errata-url>
        <doi>10.17487/RFC7599</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7600</doc-id>
        <title>IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)</title>
        <author>
            <name>R. Despres</name>
        </author>
        <author>
            <name>S. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>G. Chen</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>Coexistence</kw>
            <kw>Transition</kw>
            <kw>Interworking</kw>
            <kw>Tunneling</kw>
            <kw>Stateless</kw>
            <kw>4rd</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>Mapping</kw>
            <kw>Global Addressing</kw>
        </keywords>
        <abstract><p>This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers.  The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end.  Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.</p></abstract>
        <draft>draft-ietf-softwire-4rd-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7600</errata-url>
        <doi>10.17487/RFC7600</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7601</doc-id>
        <title>Message Header Field for Indicating Message Authentication Status</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>DomainKeys</kw>
            <kw>SenderID</kw>
            <kw>SPF</kw>
            <kw>ADSP</kw>
            <kw>ATPS</kw>
            <kw>VBR</kw>
            <kw>Authentication</kw>
            <kw>Reputation</kw>
        </keywords>
        <abstract><p>This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.</p></abstract>
        <draft>draft-ietf-appsawg-rfc7001bis-11</draft>
        <obsoletes>
            <doc-id>RFC7001</doc-id>
            <doc-id>RFC7410</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8601</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7601</errata-url>
        <doi>10.17487/RFC7601</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7602</doc-id>
        <title>IS-IS Extended Sequence Number TLV</title>
        <author>
            <name>U. Chunduri</name>
        </author>
        <author>
            <name>W. Lu</name>
        </author>
        <author>
            <name>A. Tian</name>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.</p></abstract>
        <draft>draft-ietf-isis-extended-sequence-no-tlv-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7602</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7603</doc-id>
        <title>Energy Management (EMAN) Applicability Statement</title>
        <author>
            <name>B. Schoening</name>
        </author>
        <author>
            <name>M. Chandramouli</name>
        </author>
        <author>
            <name>B. Nordman</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices.  This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices.  These use cases are useful for identifying requirements for the framework and MIBs.  Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.</p></abstract>
        <draft>draft-ietf-eman-applicability-statement-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>eman</wg_acronym>
        <doi>10.17487/RFC7603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7604</doc-id>
        <title>Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>T. Zeng</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Real-time Transport Protocol</kw>
            <kw>Real-time</kw>
            <kw>Firewall</kw>
            <kw>UDP</kw>
        </keywords>
        <abstract><p>This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol (RTSP).  Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has.  There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases.  These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document.</p></abstract>
        <draft>draft-ietf-mmusic-rtsp-nat-evaluation-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7604</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7605</doc-id>
        <title>Recommendations on Using Assigned Transport Port Numbers</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>udp</kw>
            <kw>sctp</kw>
            <kw>dccp</kw>
            <kw>service</kw>
            <kw>iana</kw>
        </keywords>
        <abstract><p>This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA.  It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.</p></abstract>
        <draft>draft-ietf-tsvwg-port-use-11</draft>
        <is-also>
            <doc-id>BCP0165</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7605</errata-url>
        <doi>10.17487/RFC7605</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7606</doc-id>
        <title>Revised Error Handling for BGP UPDATE Messages</title>
        <author>
            <name>E. Chen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Scudder</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.</p><p> This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.</p></abstract>
        <draft>draft-ietf-idr-error-handling-19</draft>
        <updates>
            <doc-id>RFC1997</doc-id>
            <doc-id>RFC4271</doc-id>
            <doc-id>RFC4360</doc-id>
            <doc-id>RFC4456</doc-id>
            <doc-id>RFC4760</doc-id>
            <doc-id>RFC5543</doc-id>
            <doc-id>RFC5701</doc-id>
            <doc-id>RFC6368</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7606</errata-url>
        <doi>10.17487/RFC7606</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7607</doc-id>
        <title>Codification of AS 0 Processing</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>H. Schiller</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>AS 0</kw>
            <kw>AS_PATH</kw>
            <kw>AS-PATH</kw>
        </keywords>
        <abstract><p>This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.</p></abstract>
        <draft>draft-ietf-idr-as0-06</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7607</errata-url>
        <doi>10.17487/RFC7607</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7608</doc-id>
        <title>IPv6 Prefix Length Recommendation for Forwarding</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>A. Petrescu</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>July</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IPv6 Routing</kw>
            <kw>CIDR</kw>
            <kw>Classless Inter-Domain Routing</kw>
            <kw>IPv6 Addressing Architecture</kw>
            <kw>IPv6 Forwarding Information Base</kw>
            <kw>IPv6 Routing Information Base</kw>
            <kw>FIB</kw>
            <kw>RIB</kw>
            <kw>IPv6 Deployment</kw>
        </keywords>
        <abstract><p>IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture.  The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix.  Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.</p></abstract>
        <draft>draft-ietf-v6ops-cidr-prefix-03</draft>
        <is-also>
            <doc-id>BCP0198</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7608</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7609</doc-id>
        <title>IBM's Shared Memory Communications over RDMA (SMC-R) Protocol</title>
        <author>
            <name>M. Fox</name>
        </author>
        <author>
            <name>C. Kassimis</name>
        </author>
        <author>
            <name>J. Stevens</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>143</page-count>
        <abstract><p>This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol.  This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications.  It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available.  It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.</p></abstract>
        <draft>draft-fox-tcpm-shared-memory-rdma-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7609</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7610</doc-id>
        <title>DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers.  It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received.  A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks.  This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.</p></abstract>
        <draft>draft-ietf-opsec-dhcpv6-shield-08</draft>
        <is-also>
            <doc-id>BCP0199</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC7610</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7611</doc-id>
        <title>BGP ACCEPT_OWN Community Attribute</title>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>D. Smith</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>VPN</kw>
            <kw>L3VPN</kw>
            <kw>Extranet</kw>
            <kw>Well-known</kw>
            <kw>Reserved</kw>
        </keywords>
        <abstract><p>Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs.  This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route.  However, due to the constraints of BGP, it does not work if the two are on the same PE.  This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.</p></abstract>
        <draft>draft-ietf-l3vpn-acceptown-community-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7611</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7612</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>June</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <abstract><p>This document defines a schema, object classes, and attributes, for Printers and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "Internet Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional Printer attributes are based on definitions in "Printer MIB v2" (RFC 3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG 5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG 5100.13), and "IPP Everywhere" (PWG 5100.14).</p><p> This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.</p><p> This document obsoletes RFC 3712.</p></abstract>
        <draft>draft-mcdonald-ldap-printer-schema-13</draft>
        <obsoletes>
            <doc-id>RFC3712</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7612</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7613</doc-id>
        <title>Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Username</kw>
            <kw>Password</kw>
            <kw>Unicode</kw>
            <kw>Internationalization</kw>
            <kw>i18n</kw>
            <kw>Authentication</kw>
            <kw>SASLprep</kw>
            <kw>strings</kw>
            <kw>stringprep</kw>
        </keywords>
        <abstract><p>This document describes updated methods for handling Unicode strings representing usernames and passwords.  The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).  The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords.  The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013.</p></abstract>
        <draft>draft-ietf-precis-saslprepbis-18</draft>
        <obsoletes>
            <doc-id>RFC4013</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8265</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>precis</wg_acronym>
        <doi>10.17487/RFC7613</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7614</doc-id>
        <title>Explicit Subscriptions for the REFER Method</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>SIP Events</kw>
            <kw>nosub</kw>
            <kw>explicitsub</kw>
            <kw>Refer-Events-At</kw>
        </keywords>
        <abstract><p>The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription.  Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing.  This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.</p></abstract>
        <draft>draft-ietf-sipcore-refer-explicit-subscription-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC7614</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7615</doc-id>
        <title>HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.</p></abstract>
        <draft>draft-ietf-httpbis-auth-info-05</draft>
        <obsoletes>
            <doc-id>RFC2617</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC7615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7616</doc-id>
        <title>HTTP Digest Access Authentication</title>
        <author>
            <name>R. Shekh-Yusef</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Ahrens</name>
        </author>
        <author>
            <name>S. Bremer</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>authentication scheme</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information.  This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.</p></abstract>
        <draft>draft-ietf-httpauth-digest-19</draft>
        <obsoletes>
            <doc-id>RFC2617</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7616</errata-url>
        <doi>10.17487/RFC7616</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7617</doc-id>
        <title>The 'Basic' HTTP Authentication Scheme</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>authentication scheme</kw>
            <kw>basic authentication scheme</kw>
        </keywords>
        <abstract><p>This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.</p></abstract>
        <draft>draft-ietf-httpauth-basicauth-update-07</draft>
        <obsoletes>
            <doc-id>RFC2617</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <doi>10.17487/RFC7617</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7618</doc-id>
        <title>Dynamic Allocation of Shared IPv4 Addresses</title>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.</p><p> Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.</p></abstract>
        <draft>draft-ietf-dhc-dynamic-shared-v4allocation-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7618</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7619</doc-id>
        <title>The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>unauthenticated</kw>
            <kw>opportunistic security</kw>
            <kw>pervasive monitoring</kw>
            <kw>Peer Authorization Database</kw>
            <kw>PAD</kw>
            <kw>opportunistic encryption</kw>
        </keywords>
        <abstract><p>This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2).  This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself.  This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-null-auth-07</draft>
        <updates>
            <doc-id>RFC4301</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC7619</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7620</doc-id>
        <title>Scenarios with Host Identification Complications</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Chatras</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>B. Williams</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IP address sharing</kw>
            <kw>IPv4 service continuity</kw>
            <kw>host identifier</kw>
            <kw>de-multiplexing connections</kw>
            <kw>policy enforcement</kw>
            <kw>service delivery</kw>
        </keywords>
        <abstract><p>This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered. This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.</p><p> This document does not include any solution-specific discussions.</p></abstract>
        <draft>draft-boucadair-intarea-host-identifier-scenarios-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7620</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7621</doc-id>
        <title>A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>session initiation protocol</kw>
        </keywords>
        <abstract><p>Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.</p><p> This document updates RFC 6665.</p></abstract>
        <draft>draft-ietf-sipcore-6665-clarification-00</draft>
        <updates>
            <doc-id>RFC6665</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC7621</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7622</doc-id>
        <title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>Messaging</kw>
            <kw>Instant Messaging</kw>
            <kw>Presence</kw>
            <kw>Internationalization</kw>
            <kw>i18n</kw>
            <kw>PRECIS</kw>
        </keywords>
        <abstract><p>This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range.  This document obsoletes RFC 6122.</p></abstract>
        <draft>draft-ietf-xmpp-6122bis-24</draft>
        <obsoletes>
            <doc-id>RFC6122</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7622</errata-url>
        <doi>10.17487/RFC7622</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7623</doc-id>
        <title>Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>A. Isaac</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes.  The combined solution is referred to as PBB-EVPN.</p></abstract>
        <draft>draft-ietf-l2vpn-pbb-evpn-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7623</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7624</doc-id>
        <title>Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>B. Schneier</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>D. Borkmann</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>eavesdropping</kw>
        </keywords>
        <abstract><p>Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered.  In this document, we develop a threat model that describes these attacks on Internet confidentiality.  We assume an attacker that is interested in undetected, indiscriminate eavesdropping.  The threat model is based on published, verified attacks.</p></abstract>
        <draft>draft-iab-privsec-confidentiality-threat-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7624</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7625</doc-id>
        <title>Architecture of an IP/MPLS Network with Hardened Pipes</title>
        <author>
            <name>J. T. Hao</name>
        </author>
        <author>
            <name>P. Maheshwari</name>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the "Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".</p><p> This document introduces the concept of a Hard Pipe -- an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.</p><p> The Hard Pipe stratum does not use statistical multiplexing; for the LSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.</p><p> The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.</p></abstract>
        <draft>draft-hao-mpls-ip-hard-pipe-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7625</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7626</doc-id>
        <title>DNS Privacy Considerations</title>
        <author>
            <name>S. Bortzmeyer</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Confidentiality</kw>
            <kw>Pervasive Surveillance</kw>
            <kw>Domain Name System</kw>
        </keywords>
        <abstract><p>This document describes the privacy issues associated with the use of the DNS by Internet users.  It is intended to be an analysis of the present situation and does not prescribe solutions.</p></abstract>
        <draft>draft-ietf-dprive-problem-statement-06</draft>
        <obsoleted-by>
            <doc-id>RFC9076</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <doi>10.17487/RFC7626</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7627</doc-id>
        <title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
        <author>
            <name>K. Bhargavan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Delignat-Lavaud</name>
        </author>
        <author>
            <name>A. Pironti</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>M. Ray</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.</p></abstract>
        <draft>draft-ietf-tls-session-hash-06</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC7627</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7628</doc-id>
        <title>A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth</title>
        <author>
            <name>W. Mills</name>
        </author>
        <author>
            <name>T. Showalter</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.</p><p> This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols.</p><p> Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.</p></abstract>
        <draft>draft-ietf-kitten-sasl-oauth-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC7628</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7629</doc-id>
        <title>Flow-Binding Support for Mobile IP</title>
        <author>
            <name>S. Gundavelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>A. Petrescu</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Multipath</kw>
            <kw>Flow Binding</kw>
            <kw>Hybrid Access</kw>
            <kw>Flow Mobility</kw>
            <kw>MIPv4-NEMO</kw>
        </keywords>
        <abstract><p>This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent.  This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic.  Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care-of addresses.</p></abstract>
        <draft>draft-ietf-mip4-multiple-tunnel-support-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>mip4</wg_acronym>
        <doi>10.17487/RFC7629</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7630</doc-id>
        <title>HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3</title>
        <author>
            <name>J. Merkle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Lochter</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>USM</kw>
            <kw>HMAC</kw>
            <kw>SHA-2</kw>
        </keywords>
        <abstract><p>This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.</p></abstract>
        <draft>draft-ietf-opsawg-hmac-sha-2-usm-snmp-06</draft>
        <obsoleted-by>
            <doc-id>RFC7860</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7630</errata-url>
        <doi>10.17487/RFC7630</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7631</doc-id>
        <title>TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>packet</kw>
            <kw>message</kw>
            <kw>address</kw>
            <kw>TLV</kw>
        </keywords>
        <abstract><p>This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork (MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.</p><p> This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444.</p></abstract>
        <draft>draft-ietf-manet-tlv-naming-05</draft>
        <updates>
            <doc-id>RFC5444</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC7722</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7632</doc-id>
        <title>Endpoint Security Posture Assessment: Enterprise Use Cases</title>
        <author>
            <name>D. Waltermire</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>security automation</kw>
            <kw>continuous monitoring</kw>
            <kw>endpoint</kw>
            <kw>posture assessment</kw>
            <kw>use case</kw>
            <kw>asset management</kw>
            <kw>configuration management</kw>
            <kw>vulnerability management</kw>
            <kw>content management</kw>
        </keywords>
        <abstract><p>This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture.  From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.</p></abstract>
        <draft>draft-ietf-sacm-use-cases-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacm</wg_acronym>
        <doi>10.17487/RFC7632</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7633</doc-id>
        <title>X.509v3 Transport Layer Security (TLS) Feature Extension</title>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>Transport Layer Security</kw>
            <kw>Cryptography Certificate</kw>
        </keywords>
        <abstract><p>The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol.  In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling.  Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled.  This in turn prevents a denial-of-service attack that might otherwise be possible.</p></abstract>
        <draft>draft-hallambaker-tlsfeature-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7633</errata-url>
        <doi>10.17487/RFC7633</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7634</doc-id>
        <title>ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IPsec</kw>
            <kw>AEAD</kw>
            <kw>ChaCha</kw>
            <kw>ChaCha20</kw>
            <kw>Salsa</kw>
        </keywords>
        <abstract><p>This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.</p></abstract>
        <draft>draft-ietf-ipsecme-chacha20-poly1305-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7634</errata-url>
        <doi>10.17487/RFC7634</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7635</doc-id>
        <title>Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization</title>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>P. Patil</name>
        </author>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>OAuth 2.0</kw>
            <kw>STUN</kw>
            <kw>TURN</kw>
            <kw>WebRTC</kw>
            <kw>Authentication and Authorization</kw>
        </keywords>
        <abstract><p>This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication.  The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.</p></abstract>
        <draft>draft-ietf-tram-turn-third-party-authz-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7635</errata-url>
        <doi>10.17487/RFC7635</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7636</doc-id>
        <title>Proof Key for Code Exchange by OAuth Public Clients</title>
        <author>
            <name>N. Sakimura</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>N. Agarwal</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>smart phones</kw>
            <kw>apps</kw>
            <kw>XARA</kw>
            <kw>authorization</kw>
            <kw>custom scheme</kw>
            <kw>intent</kw>
            <kw>man-in-the-middle</kw>
            <kw>eavesdropping</kw>
            <kw>user agent swap</kw>
            <kw>spop</kw>
            <kw>pop</kw>
            <kw>openid</kw>
            <kw>connect </kw>
            <kw>pkce</kw>
            <kw>pixie</kw>
        </keywords>
        <abstract><p>OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack.  This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").</p></abstract>
        <draft>draft-ietf-oauth-spop-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7636</errata-url>
        <doi>10.17487/RFC7636</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7637</doc-id>
        <title>NVGRE: Network Virtualization Using Generic Routing Encapsulation</title>
        <author>
            <name>P. Garg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Wang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers.  Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure.  This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.</p></abstract>
        <draft>draft-sridharan-virtualization-nvgre-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7637</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7638</doc-id>
        <title>JSON Web Key (JWK) Thumbprint</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>N. Sakimura</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>ThumbprintOB</kw>
            <kw>Fingerprint</kw>
            <kw>Digest</kw>
        </keywords>
        <abstract><p>This specification defines a method for computing a hash value over a JSON Web Key (JWK).  It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed.  The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.</p></abstract>
        <draft>draft-ietf-jose-jwk-thumbprint-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <doi>10.17487/RFC7638</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7639</doc-id>
        <title>The ALPN HTTP Header Field</title>
        <author>
            <name>A. Hutton</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>August</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>HTTP CONNECT</kw>
            <kw>Firewall</kw>
            <kw>HTTP proxy</kw>
        </keywords>
        <abstract><p>This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.</p></abstract>
        <draft>draft-ietf-httpbis-tunnel-protocol-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC7639</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7640</doc-id>
        <title>Traffic Management Benchmarking</title>
        <author>
            <name>B. Constantine</name>
        </author>
        <author>
            <name>R. Krishnan</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <abstract><p>This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.).  The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.</p></abstract>
        <draft>draft-ietf-bmwg-traffic-management-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC7640</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7641</doc-id>
        <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>K. Hartke</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Smart Objects</kw>
            <kw>Internet of Things</kw>
            <kw>IoT</kw>
            <kw>REST</kw>
        </keywords>
        <abstract><p>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</p></abstract>
        <draft>draft-ietf-core-observe-16</draft>
        <updated-by>
            <doc-id>RFC8323</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC7641</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7642</doc-id>
        <title>System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements</title>
        <author>
            <name>K. LI</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Hunt</name>
        </author>
        <author>
            <name>B. Khasnabish</name>
        </author>
        <author>
            <name>A. Nadalin</name>
        </author>
        <author>
            <name>Z. Zeltsan</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SIM user scenarios</kw>
            <kw>SCIM use cases</kw>
        </keywords>
        <abstract><p>This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM).  It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.</p></abstract>
        <draft>draft-ietf-scim-use-cases-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>scim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7642</errata-url>
        <doi>10.17487/RFC7642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7643</doc-id>
        <title>System for Cross-domain Identity Management: Core Schema</title>
        <author>
            <name>P. Hunt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Grizzle</name>
        </author>
        <author>
            <name>E. Wahlstroem</name>
        </author>
        <author>
            <name>C. Mortimore</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>104</page-count>
        <keywords>
            <kw>Identity</kw>
            <kw>Provisioning</kw>
            <kw>User</kw>
            <kw>Group</kw>
        </keywords>
        <abstract><p>The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.</p><p> This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers.</p></abstract>
        <draft>draft-ietf-scim-core-schema-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>scim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7643</errata-url>
        <doi>10.17487/RFC7643</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7644</doc-id>
        <title>System for Cross-domain Identity Management: Protocol</title>
        <author>
            <name>P. Hunt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Grizzle</name>
        </author>
        <author>
            <name>M. Ansari</name>
        </author>
        <author>
            <name>E. Wahlstroem</name>
        </author>
        <author>
            <name>C. Mortimore</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>89</page-count>
        <keywords>
            <kw>SCIM</kw>
        </keywords>
        <abstract><p>The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service.  Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios.  The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.  SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.</p></abstract>
        <draft>draft-ietf-scim-api-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>scim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7644</errata-url>
        <doi>10.17487/RFC7644</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7645</doc-id>
        <title>The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis</title>
        <author>
            <name>U. Chunduri</name>
        </author>
        <author>
            <name>A. Tian</name>
        </author>
        <author>
            <name>W. Lu</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) for both manual and automated key management protocols.</p></abstract>
        <draft>draft-ietf-karp-isis-analysis-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7645</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7646</doc-id>
        <title>Definition and Use of DNSSEC Negative Trust Anchors</title>
        <author>
            <name>P. Ebersman</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>C. Griffiths</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <author>
            <name>R. Weber</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>NTA</kw>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>Negative Trust Anchors</kw>
        </keywords>
        <abstract><p>DNS Security Extensions (DNSSEC) is now entering widespread deployment.  However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes.  This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.</p></abstract>
        <draft>draft-ietf-dnsop-negative-trust-anchors-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7646</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7647</doc-id>
        <title>Clarifications for the Use of REFER with RFC 6665</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The SIP REFER method relies on the SIP-Specific Event Notification framework.  That framework was revised by RFC 6665.  This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.</p></abstract>
        <draft>draft-ietf-sipcore-refer-clarifications-04</draft>
        <updates>
            <doc-id>RFC3515</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC7647</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7648</doc-id>
        <title>Port Control Protocol (PCP) Proxy Function</title>
        <author>
            <name>S. Perreault</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>firewall</kw>
            <kw>CGN</kw>
            <kw>AFTR</kw>
            <kw>NAT64</kw>
            <kw>port forwarding</kw>
            <kw>pinholing</kw>
            <kw>port mapping</kw>
            <kw>external IP address</kw>
            <kw>discover port number</kw>
            <kw>running a server behind NAT</kw>
            <kw>NAT control</kw>
            <kw>NAT cascading</kw>
            <kw>DS-Lite</kw>
            <kw>incoming connection</kw>
            <kw>control outbound connection</kw>
            <kw>referral</kw>
            <kw>address referral</kw>
            <kw>ALG offload</kw>
            <kw>PCP client</kw>
            <kw>PCP server</kw>
        </keywords>
        <abstract><p>This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy.  The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s).  A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.</p></abstract>
        <draft>draft-ietf-pcp-proxy-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7648</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7649</doc-id>
        <title>The Jabber Scribe Role at IETF Meetings</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>D. York</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Jabber Scribe</kw>
            <kw>IETF Meetings</kw>
        </keywords>
        <abstract><p>During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom.  Such volunteers are commonly called "Jabber scribes".  This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.</p></abstract>
        <draft>draft-saintandre-jabber-scribe-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7649</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7650</doc-id>
        <title>A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)</title>
        <author>
            <name>J. Jimenez</name>
        </author>
        <author>
            <name>J. Lopez-Vega</name>
        </author>
        <author>
            <name>J. Maenpaa</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>RELOAD</kw>
        </keywords>
        <abstract><p>This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD).  The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSNs) in a peer-to-peer fashion.  The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data.  This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers.  The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.</p></abstract>
        <draft>draft-jimenez-p2psip-coap-reload-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7650</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7651</doc-id>
        <title>3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>A. Dodd-Noble</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>F. Baboescu</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>P-CSCF</kw>
            <kw>P-CSCF Option for IKEv2</kw>
            <kw>Proxy-Call Session Control Function</kw>
            <kw>IMS Option for IKEv2</kw>
        </keywords>
        <abstract><p>This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2).  These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF).  When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.</p></abstract>
        <draft>draft-gundavelli-ipsecme-3gpp-ims-options-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7651</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7652</doc-id>
        <title>Port Control Protocol (PCP) Authentication Mechanism</title>
        <author>
            <name>M. Cullen</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <date>
            <month>September</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.</p><p> This document updates RFC 6887.</p></abstract>
        <draft>draft-ietf-pcp-authentication-14</draft>
        <updates>
            <doc-id>RFC6887</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7652</errata-url>
        <doi>10.17487/RFC7652</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7653</doc-id>
        <title>DHCPv6 Active Leasequery</title>
        <author>
            <name>D. Raghuvanshi</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>D. Kukrety</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>IPv6</kw>
            <kw>ACTIVELEASEQUERY</kw>
            <kw>DHCPv6</kw>
        </keywords>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings.  That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request.  Continuous update of an external requestor with Leasequery data is sometimes desired.  This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP.  This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-active-leasequery-04</draft>
        <updates>
            <doc-id>RFC5460</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7654</doc-id>
        <title>Benchmarking Methodology for In-Service Software Upgrade (ISSU)</title>
        <author>
            <name>S. Banks</name>
        </author>
        <author>
            <name>F. Calabria</name>
        </author>
        <author>
            <name>G. Czirjak</name>
        </author>
        <author>
            <name>R. Machat</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>Modern forwarding devices attempt to minimize any control- and data-plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service Software Upgrade (ISSU).  This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.</p></abstract>
        <draft>draft-ietf-bmwg-issu-meth-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC7654</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7655</doc-id>
        <title>RTP Payload Format for G.711.0</title>
        <author>
            <name>M. Ramalho</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>N. Harada</name>
        </author>
        <author>
            <name>M. Perumal</name>
        </author>
        <author>
            <name>L. Miao</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>G.711.0</kw>
            <kw>G.711</kw>
            <kw>G.711ZIP</kw>
            <kw>Lossless G.711 Compression</kw>
            <kw>G.711 Data Compression Algorithm</kw>
        </keywords>
        <abstract><p>This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0.  ITU-T Rec.  G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks.  This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.</p></abstract>
        <draft>draft-ietf-payload-g7110-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC7655</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7656</doc-id>
        <title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>K. Gross</name>
        </author>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>B. Burman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>Taxonomy</kw>
            <kw>Terminology</kw>
            <kw>RTP</kw>
            <kw>Grouping</kw>
        </keywords>
        <abstract><p>The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque.  This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.</p></abstract>
        <draft>draft-ietf-avtext-rtp-grouping-taxonomy-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7656</errata-url>
        <doi>10.17487/RFC7656</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7657</doc-id>
        <title>Differentiated Services (Diffserv) and Real-Time Communication</title>
        <author>
            <name>D. Black</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Diffserv</kw>
            <kw>DSCP</kw>
            <kw>RAI</kw>
            <kw>RTP</kw>
        </keywords>
        <abstract><p>This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP).  Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs).  WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple.  The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering).  In addition, DSCP markings may be changed or removed between the traffic source and destination.  This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.</p></abstract>
        <draft>draft-ietf-dart-dscp-rtp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>dart</wg_acronym>
        <doi>10.17487/RFC7657</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7658</doc-id>
        <title>Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs)</title>
        <author>
            <name>S. Perreault</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>NATV2-MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract><p>This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.</p><p> This document obsoletes RFC 4008. All MIB objects specified in RFC 4008 are included in this version unchanged with only the STATUS changed to deprecated.</p></abstract>
        <draft>draft-perrault-behave-deprecate-nat-mib-v1-06</draft>
        <obsoletes>
            <doc-id>RFC4008</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7658</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7659</doc-id>
        <title>Definitions of Managed Objects for Network Address Translators (NATs)</title>
        <author>
            <name>S. Perreault</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>NATV2-MIB</kw>
            <kw>NAT-MIB</kw>
            <kw>basic nat</kw>
            <kw>pooled nat</kw>
            <kw>carrier-grade nat</kw>
            <kw>CGN</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function.  The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008).  NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document.  A companion document deprecates all objects in NAT-MIB.  NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function.  Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN).</p></abstract>
        <draft>draft-perrault-behave-natv2-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7659</errata-url>
        <doi>10.17487/RFC7659</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7660</doc-id>
        <title>Diameter Congestion and Filter Attributes</title>
        <author>
            <name>L. Bertz</name>
        </author>
        <author>
            <name>S. Manning</name>
        </author>
        <author>
            <name>B. Hirschman</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration.</p><p> RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested.</p><p> Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.</p><p> The optional attributes defined in this document are forward and backwards compatible with RFC 5777.</p></abstract>
        <draft>draft-ietf-dime-congestion-flow-attributes-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7661</doc-id>
        <title>Updating TCP to Support Rate-Limited Traffic</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>A. Sathiaseelan</name>
        </author>
        <author>
            <name>R. Secchi</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>CWV</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.</p><p> This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.</p></abstract>
        <draft>draft-ietf-tcpm-newcwv-13</draft>
        <obsoletes>
            <doc-id>RFC2861</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC7661</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7662</doc-id>
        <title>OAuth 2.0 Token Introspection</title>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>token validation</kw>
            <kw>oauth token validation</kw>
            <kw>active token</kw>
            <kw>inactive token</kw>
            <kw>token metadata</kw>
            <kw>token status</kw>
            <kw>token status check</kw>
        </keywords>
        <abstract><p>This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token.  OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.</p></abstract>
        <draft>draft-ietf-oauth-introspection-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7662</errata-url>
        <doi>10.17487/RFC7662</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7663</doc-id>
        <title>Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)</title>
        <author>
            <name>B. Trammell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kuehlewind</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>transport layer</kw>
            <kw>TCP</kw>
            <kw>UDP</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack.  The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators).  This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop.  The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-semi-report-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7663</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7664</doc-id>
        <title>Dragonfly Key Exchange</title>
        <author>
            <name>D. Harkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>elliptic curve</kw>
            <kw>PAKE</kw>
            <kw>AKE</kw>
            <kw>dictionary attack</kw>
            <kw>password authentication</kw>
        </keywords>
        <abstract><p>This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase.  It is resistant to active attack, passive attack, and offline dictionary attack.  This document is a product of the Crypto Forum Research Group (CFRG).</p></abstract>
        <draft>draft-irtf-cfrg-dragonfly-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7664</errata-url>
        <doi>10.17487/RFC7664</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7665</doc-id>
        <title>Service Function Chaining (SFC) Architecture</title>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network.  It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF.  This document does not propose solutions, protocols, or extensions to existing protocols.</p></abstract>
        <draft>draft-ietf-sfc-architecture-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7665</errata-url>
        <doi>10.17487/RFC7665</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7666</doc-id>
        <title>Management Information Base for Virtual Machines Controlled by a Hypervisor</title>
        <author>
            <name>H. Asai</name>
        </author>
        <author>
            <name>M. MacFaden</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>K. Shima</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>Hypervisor</kw>
            <kw>Virtual Machine</kw>
            <kw>VM-MIB</kw>
            <kw>IANA-STORAGE-MEDIA-TYPE-MIB</kw>
        </keywords>
        <abstract><p>This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a.  virtual machine monitor).</p></abstract>
        <draft>draft-ietf-opsawg-vmm-mib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7666</errata-url>
        <doi>10.17487/RFC7666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7667</doc-id>
        <title>RTP Topologies</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>Real-time</kw>
            <kw>Multi-party</kw>
            <kw>Mixer</kw>
            <kw>Relay</kw>
            <kw>SFM</kw>
            <kw>Selective Forwarding Middlebox</kw>
            <kw>Translator</kw>
            <kw>Multicast</kw>
            <kw>ASM</kw>
            <kw>SSM</kw>
        </keywords>
        <abstract><p>This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP).  In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-topologies-update-10</draft>
        <obsoletes>
            <doc-id>RFC5117</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7667</errata-url>
        <doi>10.17487/RFC7667</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7668</doc-id>
        <title>IPv6 over BLUETOOTH(R) Low Energy</title>
        <author>
            <name>J. Nieminen</name>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>M. Isomaki</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>Z. Shelby</name>
        </author>
        <author>
            <name>C. Gomez</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Bluetooth Low Energy</kw>
            <kw>6lowpan</kw>
            <kw>IPv6</kw>
            <kw>Low power</kw>
        </keywords>
        <abstract><p>Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group.  The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices.  The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc.  The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6.  This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.</p></abstract>
        <draft>draft-ietf-6lo-btle-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC7668</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7669</doc-id>
        <title>Assigning Digital Object Identifiers to RFCs</title>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes the way that Digital Object Identifiers (DOIs) are assigned to past and future RFCs.  The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion.</p></abstract>
        <draft>draft-iab-doi-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7669</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7670</doc-id>
        <title>Generic Raw Public-Key Support for IKEv2</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Internet Key Exchange Version 2</kw>
        </keywords>
        <abstract><p>The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys.  In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography.  This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.</p></abstract>
        <draft>draft-kivinen-ipsecme-oob-pubkey-14</draft>
        <updates>
            <doc-id>RFC7296</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7670</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7671</doc-id>
        <title>The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance</title>
        <author>
            <name>V. Dukhovni</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>DANE</kw>
            <kw>TLSA</kw>
        </keywords>
        <abstract><p>This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience.  It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.</p></abstract>
        <draft>draft-ietf-dane-ops-16</draft>
        <updates>
            <doc-id>RFC6698</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <doi>10.17487/RFC7671</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7672</doc-id>
        <title>SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)</title>
        <author>
            <name>V. Dukhovni</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>DANE</kw>
            <kw>TLSA</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record.  Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).</p></abstract>
        <draft>draft-ietf-dane-smtp-with-dane-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7672</errata-url>
        <doi>10.17487/RFC7672</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7673</doc-id>
        <title>Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records</title>
        <author>
            <name>T. Finch</name>
        </author>
        <author>
            <name>M. Miller</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers).  However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698.  Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.</p></abstract>
        <draft>draft-ietf-dane-srv-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <doi>10.17487/RFC7673</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7674</doc-id>
        <title>Clarification of the Flowspec Redirect Extended Community</title>
        <author>
            <name>J. Haas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>bgp</kw>
            <kw>flowspec</kw>
        </keywords>
        <abstract><p>This document updates RFC 5575 ("Dissemination of Flow Specification Rules") to clarify the formatting of the BGP Flowspec Redirect Extended Community.</p></abstract>
        <draft>draft-ietf-idr-flowspec-redirect-rt-bis-05</draft>
        <obsoleted-by>
            <doc-id>RFC8955</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5575</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7674</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7675</doc-id>
        <title>Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness</title>
        <author>
            <name>M. Perumal</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>WebRTC</kw>
        </keywords>
        <abstract><p>To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.</p><p> This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</p></abstract>
        <draft>draft-ietf-rtcweb-stun-consent-freshness-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC7675</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7676</doc-id>
        <title>IPv6 Support for Generic Routing Encapsulation (GRE)</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>GRE</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.</p><p> This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.</p></abstract>
        <draft>draft-ietf-intarea-gre-ipv6-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC7676</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7677</doc-id>
        <title>SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.</p></abstract>
        <draft>draft-hansen-scram-sha256-04</draft>
        <updates>
            <doc-id>RFC5802</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9266</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7678</doc-id>
        <title>Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions</title>
        <author>
            <name>C. Zhou</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>DS-Lite</kw>
            <kw>Lightweight 4over6</kw>
            <kw>MAP-E</kw>
            <kw>IPv4 service continuity</kw>
            <kw>IPv6 deployment</kw>
            <kw>IPv4 address sharing</kw>
            <kw>Diameter</kw>
            <kw>Multicast</kw>
            <kw>IPv4 over IPv6</kw>
        </keywords>
        <abstract><p>During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6.  This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques.  To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment.  This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.</p></abstract>
        <draft>draft-ietf-dime-4over6-provisioning-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7678</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7679</doc-id>
        <title>A One-Way Delay Metric for IP Performance Metrics (IPPM)</title>
        <author>
            <name>G. Almes</name>
        </author>
        <author>
            <name>S. Kalidindi</name>
        </author>
        <author>
            <name>M. Zekauskas</name>
        </author>
        <author>
            <name>A. Morton</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Measurement</kw>
            <kw>Quality of Service (QoS)</kw>
        </keywords>
        <abstract><p>This memo defines a metric for one-way delay of packets across Internet paths.  It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document.  This memo makes RFC 2679 obsolete.</p></abstract>
        <draft>draft-ietf-ippm-2679-bis-05</draft>
        <obsoletes>
            <doc-id>RFC2679</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0081</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7679</errata-url>
        <doi>10.17487/RFC7679</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7680</doc-id>
        <title>A One-Way Loss Metric for IP Performance Metrics (IPPM)</title>
        <author>
            <name>G. Almes</name>
        </author>
        <author>
            <name>S. Kalidindi</name>
        </author>
        <author>
            <name>M. Zekauskas</name>
        </author>
        <author>
            <name>A. Morton</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Measurement</kw>
            <kw>Quality of Service (QoS)</kw>
        </keywords>
        <abstract><p>This memo defines a metric for one-way loss of packets across Internet paths.  It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document.  This memo makes RFC 2680 obsolete.</p></abstract>
        <draft>draft-ietf-ippm-2680-bis-05</draft>
        <obsoletes>
            <doc-id>RFC2680</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0082</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7680</errata-url>
        <doi>10.17487/RFC7680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7681</doc-id>
        <title>Email Exchange of Secondary School Transcripts</title>
        <author>
            <name>J. Davin</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Internet Applications</kw>
            <kw>email</kw>
            <kw>school transcript</kw>
            <kw>MIME</kw>
            <kw>OpenPGP</kw>
        </keywords>
        <abstract><p>A common format simplifies exchange of secondary school academic transcripts via electronic mail.  Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients.  By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.</p></abstract>
        <draft>draft-davin-eesst-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7681</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7682</doc-id>
        <title>Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <author>
            <name>E. Osterweil</name>
        </author>
        <author>
            <name>L. Blunk</name>
        </author>
        <author>
            <name>D. Mitchell</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Resource Certification</kw>
            <kw>Internet Routing Registry</kw>
            <kw>IRR</kw>
            <kw>Routing Policy Specification Language</kw>
            <kw>RPSL</kw>
        </keywords>
        <abstract><p>The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades.  Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.</p></abstract>
        <draft>draft-ietf-grow-irr-routing-policy-considerations-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC7682</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7683</doc-id>
        <title>Diameter Overload Indication Conveyance</title>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Donovan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>L. Morand</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>DOIC</kw>
        </keywords>
        <abstract><p>This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC).</p></abstract>
        <draft>draft-ietf-dime-ovli-10</draft>
        <updated-by>
            <doc-id>RFC8581</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7683</errata-url>
        <doi>10.17487/RFC7683</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7684</doc-id>
        <title>OSPFv2 Prefix/Link Attribute Advertisement</title>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>OSPF-LSA</kw>
            <kw>open shortest path first</kw>
            <kw>link state advertisement</kw>
            <kw>Opaque LSA</kw>
        </keywords>
        <abstract><p>OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328.  This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links.  Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs.  The OSPFv2 Opaque LSAs are optional and fully backward compatible.</p></abstract>
        <draft>draft-ietf-ospf-prefix-link-attr-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7684</errata-url>
        <doi>10.17487/RFC7684</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7685</doc-id>
        <title>A Transport Layer Security (TLS) ClientHello Padding Extension</title>
        <author>
            <name>A. Langley</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.</p></abstract>
        <draft>draft-ietf-tls-padding-04</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC7685</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7686</doc-id>
        <title>The ".onion" Special-Use Domain Name</title>
        <author>
            <name>J. Appelbaum</name>
        </author>
        <author>
            <name>A. Muffett</name>
        </author>
        <date>
            <month>October</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document registers the ".onion" Special-Use Domain Name.</p></abstract>
        <draft>draft-ietf-dnsop-onion-tld-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7686</errata-url>
        <doi>10.17487/RFC7686</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7687</doc-id>
        <title>Report from the Strengthening the Internet (STRINT) Workshop</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>R. Wenning</name>
        </author>
        <author>
            <name>B. Bos</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>W3C</kw>
            <kw>STREWS</kw>
            <kw>security</kw>
            <kw>pervasive monitoring</kw>
            <kw>London</kw>
        </keywords>
        <abstract><p>The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-strint-report-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7687</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7688</doc-id>
        <title>GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.</p><p> This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.</p></abstract>
        <draft>draft-ietf-ccamp-wson-signal-compatibility-ospf-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7688</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7689</doc-id>
        <title>Signaling Extensions for Wavelength Switched Optical Networks</title>
        <author>
            <name>G. Bernstein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Xu</name>
        </author>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Martinelli</name>
        </author>
        <author>
            <name>H. Harai</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs).  Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes.  This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.</p></abstract>
        <draft>draft-ietf-ccamp-wson-signaling-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7689</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7690</doc-id>
        <title>Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))</title>
        <author>
            <name>M. Byerly</name>
        </author>
        <author>
            <name>M. Hite</name>
        </author>
        <author>
            <name>J. Jaeggli</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>ICMP6</kw>
            <kw>ICMPv6 type 2 PTB</kw>
        </keywords>
        <abstract><p>This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures.  It discusses operational mitigations that can be employed to address this class of failures.</p></abstract>
        <draft>draft-ietf-v6ops-pmtud-ecmp-problem-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7690</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7691</doc-id>
        <title>Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members</title>
        <author>
            <name>S. Bradner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>BCP 101 defines the start and end dates for the terms of IETF Administrative Oversight Committee (IAOC) members; these terms have proven to be impractical.  This memo updates BCP 101 to direct the IAOC to establish more practical start and end dates for terms of IAOC members.</p></abstract>
        <draft>draft-bradner-iaoc-terms-04</draft>
        <obsoleted-by>
            <doc-id>RFC8711</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4071</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7691</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7692</doc-id>
        <title>Compression Extensions for WebSocket</title>
        <author>
            <name>T. Yoshino</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>DEFLATE</kw>
            <kw>LZ77</kw>
        </keywords>
        <abstract><p>This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol.  An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake.  This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages.  Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail.  This document also specifies one specific compression extension using the DEFLATE algorithm.</p></abstract>
        <draft>draft-ietf-hybi-permessage-compression-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>hybi</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7692</errata-url>
        <doi>10.17487/RFC7692</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7693</doc-id>
        <title>The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)</title>
        <author>
            <name>M-J. Saarinen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J-P. Aumasson</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>BLAKE2</kw>
            <kw>Cryptographic Hash</kw>
        </keywords>
        <abstract><p>This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community.  BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures.  BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).</p></abstract>
        <draft>draft-saarinen-blake2-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7693</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7694</doc-id>
        <title>Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>content-encoding</kw>
        </keywords>
        <abstract><p>In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.</p><p> Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.</p></abstract>
        <draft>draft-ietf-httpbis-cice-03</draft>
        <obsoleted-by>
            <doc-id>RFC9110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC7694</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7695</doc-id>
        <title>Distributed Prefix Assignment Algorithm</title>
        <author>
            <name>P. Pfister</name>
        </author>
        <author>
            <name>B. Paterson</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>distributed</kw>
            <kw>prefix</kw>
            <kw>address</kw>
            <kw>assignment</kw>
            <kw>homenet</kw>
        </keywords>
        <abstract><p>This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping.  Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated.</p></abstract>
        <draft>draft-ietf-homenet-prefix-assignment-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <doi>10.17487/RFC7695</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7696</doc-id>
        <title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature.  Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly.  This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.</p></abstract>
        <draft>draft-iab-crypto-alg-agility-08</draft>
        <is-also>
            <doc-id>BCP0201</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7696</errata-url>
        <doi>10.17487/RFC7696</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7697</doc-id>
        <title>MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)</title>
        <author>
            <name>P. Pan</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>M. Venkatesan</name>
        </author>
        <author>
            <name>K. Sampath</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>MPLS-OAM-ID-STD-MIB</kw>
        </keywords>
        <abstract><p>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 to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP).</p></abstract>
        <draft>draft-ietf-mpls-tp-oam-id-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7697</errata-url>
        <doi>10.17487/RFC7697</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7698</doc-id>
        <title>Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks</title>
        <author>
            <name>O. Gonzalez de Dios</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Casellas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>X. Fu</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>I. Hussain</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>DWDM</kw>
            <kw>Flexi-Grid</kw>
            <kw>GMPLS</kw>
        </keywords>
        <abstract><p>To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid).</p><p> Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents.</p></abstract>
        <draft>draft-ietf-ccamp-flexi-grid-fwk-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7698</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7699</doc-id>
        <title>Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>RSVP-TE</kw>
        </keywords>
        <abstract><p>GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.</p><p> This document updates RFCs 3471 and 6205 by introducing a new label format.</p></abstract>
        <draft>draft-ietf-ccamp-flexigrid-lambda-label-05</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
            <doc-id>RFC6205</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7699</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7700</doc-id>
        <title>Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>nickname</kw>
            <kw>SIP</kw>
            <kw>SIMPLE</kw>
            <kw>XMPP</kw>
            <kw>MSRP</kw>
            <kw>XCON</kw>
            <kw>chatrooms</kw>
        </keywords>
        <abstract><p>This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities.</p></abstract>
        <draft>draft-ietf-precis-nickname-19</draft>
        <obsoleted-by>
            <doc-id>RFC8266</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>precis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7700</errata-url>
        <doi>10.17487/RFC7700</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7701</doc-id>
        <title>Multi-party Chat Using the Message Session Relay Protocol (MSRP)</title>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>G. Sandbakken</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>messaging</kw>
            <kw>message sessions</kw>
            <kw>multi-party</kw>
            <kw>chat</kw>
            <kw>MSRP</kw>
            <kw>SIMPLE</kw>
        </keywords>
        <abstract><p>The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).  This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.</p></abstract>
        <draft>draft-ietf-simple-chat-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rai</area>
        <wg_acronym>simple</wg_acronym>
        <doi>10.17487/RFC7701</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7702</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>S. Ibarra</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>Text Chat</kw>
            <kw>Groupchat</kw>
            <kw>Instant Messaging</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>SIP</kw>
            <kw>Message Sessions Relay Protocol</kw>
            <kw>MSRP</kw>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>XMPP</kw>
        </keywords>
        <abstract><p>This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP).  Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.</p></abstract>
        <draft>draft-ietf-stox-groupchat-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stox</wg_acronym>
        <doi>10.17487/RFC7702</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7703</doc-id>
        <title>Experience with Testing of Mapping of Address and Port Using Translation (MAP-T)</title>
        <author>
            <name>E. Cordeiro</name>
        </author>
        <author>
            <name>R. Carnier</name>
        </author>
        <author>
            <name>A. Moreiras</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>template</kw>
        </keywords>
        <abstract><p>This document describes the testing result of a network utilizing a Mapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.</p><p> The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.</p></abstract>
        <draft>draft-cordeiro-experience-mapt-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7703</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7704</doc-id>
        <title>An IETF with Much Diversity and Professional Conduct</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>N. Clark</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations.  During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions.  In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content.  Groups with greater diversity make better decisions.  Obtaining meaningful diversity requires more than generic good will and statements of principle.  Many different behaviors can serve to reduce participant diversity or participation diversity.  This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it.  The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF.</p></abstract>
        <draft>draft-crocker-diversity-conduct-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7704</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7705</doc-id>
        <title>Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute</title>
        <author>
            <name>W. George</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>as-migration</kw>
            <kw>AS-migration</kw>
            <kw>AS_migration</kw>
            <kw>AS migration</kw>
            <kw>IDR</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification.  It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.</p></abstract>
        <draft>draft-ietf-idr-as-migration-06</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7705</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7706</doc-id>
        <title>Decreasing Access Time to Root Servers by Running One on Loopback</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server.  Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties.  Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1).  This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.</p></abstract>
        <draft>draft-ietf-dnsop-root-loopback-05</draft>
        <obsoleted-by>
            <doc-id>RFC8806</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7706</errata-url>
        <doi>10.17487/RFC7706</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7707</doc-id>
        <title>Network Reconnaissance in IPv6 Networks</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>IPv6 offers a much larger address space than that of its IPv4 counterpart.  An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses.  As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible.  This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.</p></abstract>
        <draft>draft-ietf-opsec-ipv6-host-scanning-08</draft>
        <obsoletes>
            <doc-id>RFC5157</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7707</errata-url>
        <doi>10.17487/RFC7707</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7708</doc-id>
        <title>Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>VCCV</kw>
            <kw>GAL</kw>
        </keywords>
        <abstract><p>The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW).  This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network.  This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data.  This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).</p></abstract>
        <draft>draft-ietf-pals-vccv-for-gal-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7708</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7709</doc-id>
        <title>Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Wilson</name>
        </author>
        <author>
            <name>G. Clapp</name>
        </author>
        <author>
            <name>V. Shukla</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>generalized multiprotocol label switching</kw>
            <kw>OTN</kw>
            <kw>optical transport networks</kw>
            <kw>WSON</kw>
            <kw> TDM</kw>
            <kw>WDM</kw>
            <kw>churn</kw>
            <kw>on-demand</kw>
            <kw>wavelength</kw>
            <kw>rapid setup</kw>
        </keywords>
        <abstract><p>Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.</p><p> The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).</p></abstract>
        <draft>draft-ietf-teas-fast-lsps-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7709</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7710</doc-id>
        <title>Captive-Portal Identification Using DHCP or Router Advertisements (RAs)</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>P. Ebersman</name>
        </author>
        <author>
            <name>S. Sheng</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.</p><p> This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document.</p></abstract>
        <draft>draft-wkumari-dhc-capport-16</draft>
        <obsoleted-by>
            <doc-id>RFC8910</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7710</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7711</doc-id>
        <title>PKIX over Secure HTTP (POSH)</title>
        <author>
            <name>M. Miller</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>Jabber</kw>
            <kw>federation</kw>
        </keywords>
        <abstract><p>Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments.  As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain.  Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security.  This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols.  Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.</p></abstract>
        <draft>draft-ietf-xmpp-posh-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>xmpp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7711</errata-url>
        <doi>10.17487/RFC7711</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7712</doc-id>
        <title>Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>M. Miller</name>
        </author>
        <author>
            <name>P. Hancke</name>
        </author>
        <date>
            <month>November</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>XMPP</kw>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>Jabber</kw>
            <kw>federation</kw>
            <kw>delegation</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways.  First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes".  Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.</p></abstract>
        <draft>draft-ietf-xmpp-dna-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>xmpp</wg_acronym>
        <doi>10.17487/RFC7712</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7713</doc-id>
        <title>Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Congestion Control</kw>
            <kw>Signaling</kw>
            <kw>Protocol</kw>
            <kw>Encoding</kw>
            <kw>Audit</kw>
            <kw>Policing</kw>
        </keywords>
        <abstract><p>This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow.  Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback.  The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management.  This mechanism is called Congestion Exposure, or ConEx.  The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.</p></abstract>
        <draft>draft-ietf-conex-abstract-mech-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>conex</wg_acronym>
        <doi>10.17487/RFC7713</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7714</doc-id>
        <title>AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>K. Igoe</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <abstract><p>This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).</p></abstract>
        <draft>draft-ietf-avtcore-srtp-aes-gcm-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7714</errata-url>
        <doi>10.17487/RFC7714</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7715</doc-id>
        <title>Multipoint LDP (mLDP) Node Protection</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP).  In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails.  Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs).  The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.</p></abstract>
        <draft>draft-ietf-mpls-mldp-node-protection-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7716</doc-id>
        <title>Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures</title>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>L. Giuliano</name>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Subramanian</name>
        </author>
        <author>
            <name>D. Pacella</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers.  Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network.  With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN.  Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast".  In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.</p></abstract>
        <draft>draft-ietf-bess-mvpn-global-table-mcast-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7717</doc-id>
        <title>IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>K. Pentikousis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Zhang</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret.  This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP.  If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency.  The key derivation presented in this document can also facilitate automatic key management.</p></abstract>
        <draft>draft-ietf-ippm-ipsec-11</draft>
        <updates>
            <doc-id>RFC4656</doc-id>
            <doc-id>RFC5357</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7717</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7718</doc-id>
        <title>Registries for the One-Way Active Measurement Protocol (OWAMP)</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol.  The registries allow assignment of Mode bit positions and OWAMP Command numbers.  Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry.  This memo updates RFC 4656.</p></abstract>
        <draft>draft-ietf-ippm-owamp-registry-03</draft>
        <updates>
            <doc-id>RFC4656</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7719</doc-id>
        <title>DNS Terminology</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>A. Sullivan</name>
        </author>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>The DNS is defined in literally dozens of different RFCs.  The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of the terms used in the DNS in a single document.</p></abstract>
        <draft>draft-ietf-dnsop-dns-terminology-05</draft>
        <obsoleted-by>
            <doc-id>RFC8499</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7719</errata-url>
        <doi>10.17487/RFC7719</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7720</doc-id>
        <title>DNS Root Name Service Protocol and Deployment Requirements</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>L-J. Liman</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The DNS root name service is a critical part of the Internet architecture.  The protocol and deployment requirements for the DNS root name service are defined in this document.  Operational requirements are out of scope.</p></abstract>
        <draft>draft-iab-2870bis-03</draft>
        <obsoletes>
            <doc-id>RFC2870</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>
        <stream>IETF</stream>
        <wg_acronym>IESG</wg_acronym>
        <doi>10.17487/RFC7720</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7721</doc-id>
        <title>Security and Privacy Considerations for IPv6 Address Generation Mechanisms</title>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized.  It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.</p></abstract>
        <draft>draft-ietf-6man-ipv6-address-generation-privacy-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7721</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7722</doc-id>
        <title>Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.</p><p> This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.</p></abstract>
        <draft>draft-ietf-manet-olsrv2-multitopology-07</draft>
        <updates>
            <doc-id>RFC7188</doc-id>
            <doc-id>RFC7631</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7722</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7723</doc-id>
        <title>Port Control Protocol (PCP) Anycast Addresses</title>
        <author>
            <name>S. Kiesel</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Port Control Protocol</kw>
            <kw>anycast address</kw>
            <kw>anycast server discovery</kw>
            <kw>Port Control Protocol server discovery</kw>
            <kw>port mapping</kw>
            <kw>NAT control</kw>
            <kw>firewall control</kw>
        </keywords>
        <abstract><p>The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel.  This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.</p></abstract>
        <draft>draft-ietf-pcp-anycast-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7723</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7724</doc-id>
        <title>Active DHCPv4 Lease Query</title>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>N. Russell</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388).  That mechanism is limited to queries for individual bindings.  In some situations, individual binding queries may not be efficient, or even possible.  In addition, continuous update of an external requestor with Leasequery data is sometimes desired.  This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP.  This document updates RFC 6926, "DHCPv4 Bulk Leasequery".</p></abstract>
        <draft>draft-ietf-dhc-dhcpv4-active-leasequery-07</draft>
        <updates>
            <doc-id>RFC6926</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7724</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7725</doc-id>
        <title>An HTTP Status Code to Report Legal Obstacles</title>
        <author>
            <name>T. Bray</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
        </keywords>
        <abstract><p>This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.</p></abstract>
        <draft>draft-ietf-httpbis-legally-restricted-status-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7725</errata-url>
        <doi>10.17487/RFC7725</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7726</doc-id>
        <title>Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>V. Govindan</name>
        </author>
        <author>
            <name>K. Rajaraman</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RFC5884</kw>
            <kw>MPLS</kw>
            <kw>LSP</kw>
            <kw>BFD</kw>
            <kw>RFC 5884</kw>
        </keywords>
        <abstract><p>This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given &lt;MPLS LSP, FEC&gt; as described in RFC 5884.</p></abstract>
        <draft>draft-ietf-bfd-rfc5884-clarifications-04</draft>
        <updates>
            <doc-id>RFC5884</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC7726</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7727</doc-id>
        <title>Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)</title>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>H. Wen</name>
        </author>
        <author>
            <name>J. Hu</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.</p><p> In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.</p></abstract>
        <draft>draft-ietf-pwe3-iccp-stp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7727</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7728</doc-id>
        <title>RTP Stream Pause and Resume</title>
        <author>
            <name>B. Burman</name>
        </author>
        <author>
            <name>A. Akram</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>CCM</kw>
            <kw>RTCP</kw>
            <kw>Feedback</kw>
            <kw>Bandwidth</kw>
            <kw>PAUSED</kw>
            <kw>REFUSED</kw>
            <kw>TMMBR</kw>
            <kw>TMMBN</kw>
            <kw>Mixer</kw>
            <kw>MCU</kw>
        </keywords>
        <abstract><p>With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions.  This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport.  This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams.  This document updates RFC 5104.</p></abstract>
        <draft>draft-ietf-avtext-rtp-stream-pause-10</draft>
        <updates>
            <doc-id>RFC5104</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7728</errata-url>
        <doi>10.17487/RFC7728</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7729</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management</title>
        <author>
            <name>B. Khasnabish</name>
        </author>
        <author>
            <name>E. Haleplidis</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>LFB</kw>
            <kw>Subsidiary Management</kw>
            <kw>Virtualization</kw>
        </keywords>
        <abstract><p>Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding.  In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality.  We refer to this LFB as the Subsidiary Mechanism (SM) LFB.  A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB.  This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE.  The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.</p></abstract>
        <draft>draft-ietf-forces-lfb-subsidiary-management-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7729</errata-url>
        <doi>10.17487/RFC7729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7730</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Trust Anchor Locator</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>BGP Security</kw>
        </keywords>
        <abstract><p>This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI).  This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.</p></abstract>
        <draft>draft-ietf-sidr-rfc6490-bis-05</draft>
        <obsoletes>
            <doc-id>RFC6490</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC8630</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC7730</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7731</doc-id>
        <title>Multicast Protocol for Low-Power and Lossy Networks (MPL)</title>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>R. Kelsey</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>6lowpan</kw>
            <kw>802.15.4</kw>
            <kw>IPv6</kw>
            <kw>LLN</kw>
            <kw>ROLL</kw>
            <kw>mesh network</kw>
            <kw>trickle</kw>
            <kw>wsn</kw>
            <kw>wireless sensor network</kw>
        </keywords>
        <abstract><p>This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.</p><p> MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.</p></abstract>
        <draft>draft-ietf-roll-trickle-mcast-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC7731</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7732</doc-id>
        <title>Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)</title>
        <author>
            <name>P. van der Stok</name>
        </author>
        <author>
            <name>R. Cragie</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>MPL</kw>
            <kw>multicast policy</kw>
            <kw>IP networks</kw>
        </keywords>
        <abstract><p>The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.</p></abstract>
        <draft>draft-ietf-roll-admin-local-policy-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC7732</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7733</doc-id>
        <title>Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control</title>
        <author>
            <name>A. Brandt</name>
        </author>
        <author>
            <name>E. Baccelli</name>
        </author>
        <author>
            <name>R. Cragie</name>
        </author>
        <author>
            <name>P. van der Stok</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>sensor network</kw>
            <kw>ad hoc network</kw>
            <kw>routing</kw>
            <kw>RPL</kw>
            <kw>applicability</kw>
            <kw>building control</kw>
            <kw>home automation</kw>
            <kw>IP networks</kw>
        </keywords>
        <abstract><p>The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.</p></abstract>
        <draft>draft-ietf-roll-applicability-home-building-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC7733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7734</doc-id>
        <title>Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)</title>
        <author>
            <name>D. Allan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SPBM</kw>
            <kw>Provider Backbone Bridging Provider Edges</kw>
            <kw>PBB-EVPN</kw>
        </keywords>
        <abstract><p>This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623).  This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.</p></abstract>
        <draft>draft-ietf-bess-spbm-evpn-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7734</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7735</doc-id>
        <title>Tracking Reviews of Documents</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>review tool requirements</kw>
        </keywords>
        <abstract><p>Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs.  The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker.  This document discusses requirements for improving those tools without disrupting current work flows.</p></abstract>
        <draft>draft-sparks-genarea-review-tracker-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7735</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7736</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Media Type Registration</title>
        <author>
            <name>K. Ma</name>
        </author>
        <date>
            <month>December</month>
            <year>2015</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>CDNI</kw>
            <kw>CDN Interconnect</kw>
            <kw>CDN</kw>
            <kw>content delivery</kw>
            <kw>content delivery network</kw>
        </keywords>
        <abstract><p>This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.</p></abstract>
        <draft>draft-ietf-cdni-media-type-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC7736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7737</doc-id>
        <title>Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification</title>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LSP Ping</kw>
            <kw>Reply Mode</kw>
        </keywords>
        <abstract><p>The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply.  This document updates the procedures for the "Reply via Specified Path" Reply Mode.  The value of this Reply Mode is 5.  The update creates a simple way to indicate that the reverse LSP should be used as the return path.  This document also adds an optional TLV that can carry an ordered list of Reply Mode values.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-reply-mode-simple-05</draft>
        <updates>
            <doc-id>RFC7110</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7738</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <author>
            <name>A. Schiltknecht</name>
        </author>
        <author>
            <name>P. Shames</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).</p></abstract>
        <draft>draft-blanchet-ccsds-urn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7739</doc-id>
        <title>Security Implications of Predictable Fragment Identification Values</title>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>attack</kw>
            <kw>vulnerability</kw>
            <kw>Denial of Service</kw>
            <kw>protocol identifiers</kw>
        </keywords>
        <abstract><p>IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms.  The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host.  The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address.  Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values.  This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.</p></abstract>
        <draft>draft-ietf-6man-predictable-fragment-id-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC7739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7740</doc-id>
        <title>Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>A. Dolganow</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MVPN</kw>
            <kw>Ingress Replication</kw>
            <kw>Bidirectional C-flow</kw>
            <kw>p-tunnel</kw>
        </keywords>
        <abstract><p>RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels.  This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication.  This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.</p></abstract>
        <draft>draft-ietf-bess-mvpn-bidir-ingress-replication-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7740</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7741</doc-id>
        <title>RTP Payload Format for VP8 Video</title>
        <author>
            <name>P. Westin</name>
        </author>
        <author>
            <name>H. Lundin</name>
        </author>
        <author>
            <name>M. Glover</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>F. Galligan</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>V8</kw>
            <kw>WebM</kw>
        </keywords>
        <abstract><p>This memo describes an RTP payload format for the VP8 video codec.  The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.</p></abstract>
        <draft>draft-ietf-payload-vp8-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC7741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7742</doc-id>
        <title>WebRTC Video Processing and Codec Requirements</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MTI</kw>
            <kw>mandatory-to-implement</kw>
        </keywords>
        <abstract><p>This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network.  It specifies the video processing that is required as well as video codecs and their parameters.</p></abstract>
        <draft>draft-ietf-rtcweb-video-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC7742</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7743</doc-id>
        <title>Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping</title>
        <author>
            <name>J. Luo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Jin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute.  This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator.  This document updates RFC 4379.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-relay-reply-11</draft>
        <updates>
            <doc-id>RFC4379</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7743</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7744</doc-id>
        <title>Use Cases for Authentication and Authorization in Constrained Environments</title>
        <author>
            <name>L. Seitz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gerdes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>M. Mani</name>
        </author>
        <author>
            <name>S. Kumar</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Internet of Things</kw>
            <kw>IoT</kw>
            <kw>Smart Object</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.</p><p> This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.</p><p> Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.</p></abstract>
        <draft>draft-ietf-ace-usecases-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC7744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7745</doc-id>
        <title>XML Schemas for Reverse DNS Management</title>
        <author>
            <name>T. Manderson</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment.  This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.</p></abstract>
        <draft>draft-manderson-rdns-xml-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7746</doc-id>
        <title>Label Switched Path (LSP) Self-Ping</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>M. Conn</name>
        </author>
        <author>
            <name>D. Pacella</name>
        </author>
        <author>
            <name>L. Tomotaki</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.</p><p> This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.</p><p> LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.</p><p> LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.</p></abstract>
        <draft>draft-ietf-mpls-self-ping-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7746</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7747</doc-id>
        <title>Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence</title>
        <author>
            <name>R. Papneja</name>
        </author>
        <author>
            <name>B. Parise</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>D. Lee</name>
        </author>
        <author>
            <name>I. Varlashkin</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>BMWG</kw>
        </keywords>
        <abstract><p>BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol.  It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed.  This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.</p></abstract>
        <draft>draft-ietf-bmwg-bgp-basic-convergence-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC7747</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7748</doc-id>
        <title>Elliptic Curves for Security</title>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>M. Hamburg</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>elliptic curve</kw>
            <kw>cryptography</kw>
            <kw>ecc</kw>
        </keywords>
        <abstract><p>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</p></abstract>
        <draft>draft-irtf-cfrg-curves-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7748</errata-url>
        <doi>10.17487/RFC7748</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7749</doc-id>
        <title>The "xml2rfc" Version 2 Vocabulary</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>76</page-count>
        <keywords>
            <kw>XML</kw>
            <kw>IETF</kw>
            <kw>RFC</kw>
            <kw>Internet-Draft</kw>
            <kw>Vocabulary</kw>
        </keywords>
        <abstract><p>This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.</p><p> Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.</p><p> This document obsoletes RFC 2629.</p></abstract>
        <draft>draft-iab-xml2rfcv2-02</draft>
        <obsoletes>
            <doc-id>RFC2629</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC7991</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7749</errata-url>
        <doi>10.17487/RFC7749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7750</doc-id>
        <title>Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>J. Hedin</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>S. Baillargeon</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>TWAMP</kw>
            <kw>Type-P Descriptor</kw>
        </keywords>
        <abstract><p>This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.</p></abstract>
        <draft>draft-ietf-ippm-type-p-monitor-03</draft>
        <updates>
            <doc-id>RFC5357</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7750</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7751</doc-id>
        <title>Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)</title>
        <author>
            <name>S. Sorce</name>
        </author>
        <author>
            <name>T. Yu</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Kerberos</kw>
        </keywords>
        <abstract><p>This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED.  It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements.  The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container.  This document updates RFC 4120.</p></abstract>
        <draft>draft-ietf-kitten-cammac-04</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC7751</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7752</doc-id>
        <title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
        <author>
            <name>H. Gredler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Medved</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>S. Ray</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>North-Bound</kw>
            <kw>API</kw>
            <kw>Link-State</kw>
            <kw>Topology</kw>
            <kw>Controller</kw>
            <kw>Multi-Area</kw>
            <kw>Multi-AS</kw>
        </keywords>
        <abstract><p>In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</p><p> This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.</p><p> Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</p></abstract>
        <draft>draft-ietf-idr-ls-distribution-13</draft>
        <obsoleted-by>
            <doc-id>RFC9552</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC9029</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7752</errata-url>
        <doi>10.17487/RFC7752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7753</doc-id>
        <title>Port Control Protocol (PCP) Extension for Port-Set Allocation</title>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>S. Perreault</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IPv4 service continuity</kw>
            <kw>IPv4 address shortage</kw>
            <kw>A+P</kw>
            <kw>AplusP</kw>
            <kw>address plus port</kw>
            <kw>MAP</kw>
            <kw>Port range</kw>
            <kw>Port Range Router</kw>
            <kw>MAP-E</kw>
            <kw>port set mapping</kw>
            <kw>port bulk</kw>
        </keywords>
        <abstract><p>In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set.  This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole.  This is accomplished using a new MAP option: PORT_SET.</p></abstract>
        <draft>draft-ietf-pcp-port-set-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7753</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7754</doc-id>
        <title>Technical Considerations for Internet Service Blocking and Filtering</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>O. Kolkman</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Firewall</kw>
            <kw>Filter</kw>
            <kw>Deep Packet Inspection</kw>
            <kw>Domain Name Seizure</kw>
            <kw>Web Portal</kw>
            <kw>Web Proxy</kw>
        </keywords>
        <abstract><p>The Internet is structured to be an open communications medium.  This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties.  Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications.  Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications.  This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture.  When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications.  We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.</p></abstract>
        <draft>draft-iab-filtering-considerations-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7755</doc-id>
        <title>SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments</title>
        <author>
            <name>T. Anderson</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Data Centre</kw>
            <kw>Data Center</kw>
            <kw>Dual Stack</kw>
            <kw>Single Stack</kw>
            <kw>IDC</kw>
            <kw>IPv4</kw>
            <kw>IPv4 conservation</kw>
            <kw>IPv4 exhaustion</kw>
            <kw>IPv6-only</kw>
            <kw>IPv6 only</kw>
            <kw>IPv6 transition</kw>
            <kw>IPv6 transition technology</kw>
            <kw>XLAT</kw>
        </keywords>
        <abstract><p>This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.</p><p> The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.</p></abstract>
        <draft>draft-ietf-v6ops-siit-dc-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7755</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7756</doc-id>
        <title>Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode</title>
        <author>
            <name>T. Anderson</name>
        </author>
        <author>
            <name>S. Steffann</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Data Centre</kw>
            <kw>Data Center</kw>
            <kw>Dual Stack</kw>
            <kw>Single Stack</kw>
            <kw>IDC</kw>
            <kw>IPv4</kw>
            <kw>IPv4 conservation</kw>
            <kw>IPv4 exhaustion</kw>
            <kw>IPv6-only</kw>
            <kw>IPv6 only</kw>
            <kw>IPv6 transition</kw>
            <kw>IPv6 transition technology</kw>
            <kw>XLAT</kw>
        </keywords>
        <abstract><p>This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.</p><p> The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.</p></abstract>
        <draft>draft-ietf-v6ops-siit-dc-2xlat-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7756</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7757</doc-id>
        <title>Explicit Address Mappings for Stateless IP/ICMP Translation</title>
        <author>
            <name>T. Anderson</name>
        </author>
        <author>
            <name>A. Leiva Popper</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Dual Stack</kw>
            <kw>Single Stack</kw>
            <kw>IPv4</kw>
            <kw>IPv4 conservation</kw>
            <kw>IPv4 exhaustion</kw>
            <kw>IPv6-only</kw>
            <kw>IPv6 only</kw>
            <kw>IPv6 transition</kw>
            <kw>IPv6 transition technology</kw>
            <kw>XLAT</kw>
        </keywords>
        <abstract><p>This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145.  The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.</p></abstract>
        <draft>draft-ietf-v6ops-siit-eam-03</draft>
        <updates>
            <doc-id>RFC6145</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7758</doc-id>
        <title>Time Capability in NETCONF</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>Y. Moses</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>network management</kw>
            <kw>time</kw>
            <kw>clock synchronization</kw>
        </keywords>
        <abstract><p>This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations.  This extension allows NETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.</p></abstract>
        <draft>draft-mm-netconf-time-capability-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7759</doc-id>
        <title>Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping</title>
        <author>
            <name>E. Bellagamba</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>P. Skoldstrom</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>LSP-PING</kw>
            <kw>MPLS</kw>
            <kw>MPLS-TP</kw>
            <kw> OAM</kw>
        </keywords>
        <abstract><p>This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7759</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7760</doc-id>
        <title>Statement of Work for Extensions to the IETF Datatracker for Author Statistics</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.</p></abstract>
        <draft>draft-housley-sow-author-statistics-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7760</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7761</doc-id>
        <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>H. Holbrook</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <author>
            <name>R. Parekh</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>L. Zheng</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>137</page-count>
        <abstract><p>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</p><p> This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</p></abstract>
        <draft>draft-ietf-pim-rfc4601bis-06</draft>
        <obsoletes>
            <doc-id>RFC4601</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8736</doc-id>
            <doc-id>RFC9436</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0083</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7761</errata-url>
        <doi>10.17487/RFC7761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7762</doc-id>
        <title>Initial Assignment for the Content Security Policy Directives Registry</title>
        <author>
            <name>M. West</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content Security Policy Level 2 specification.</p></abstract>
        <draft>draft-west-webappsec-csp-reg-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7763</doc-id>
        <title>The text/markdown Media Type</title>
        <author>
            <name>S. Leonard</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.</p></abstract>
        <draft>draft-ietf-appsawg-text-markdown-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7764</doc-id>
        <title>Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations</title>
        <author>
            <name>S. Leonard</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>text/markdown</kw>
        </keywords>
        <abstract><p>This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.  Background information, local storage strategies, and additional syntax registrations are supplied.</p></abstract>
        <draft>draft-ietf-appsawg-text-markdown-use-cases-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC7764</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7765</doc-id>
        <title>TCP and Stream Control Transmission Protocol (SCTP) RTO Restart</title>
        <author>
            <name>P. Hurtig</name>
        </author>
        <author>
            <name>A. Brunstrom</name>
        </author>
        <author>
            <name>A. Petlund</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>retransmission timer</kw>
            <kw>rtor</kw>
        </keywords>
        <abstract><p>This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection.  The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used.  This enables faster loss detection and recovery for connections that are short lived or application limited.</p></abstract>
        <draft>draft-ietf-tcpm-rtorestart-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC7765</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7766</doc-id>
        <title>DNS Transport over TCP - Implementation Requirements</title>
        <author>
            <name>J. Dickinson</name>
        </author>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>R. Bellis</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>TCP/IP</kw>
            <kw>transport</kw>
        </keywords>
        <abstract><p>This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP.  This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</p></abstract>
        <draft>draft-ietf-dnsop-5966bis-06</draft>
        <obsoletes>
            <doc-id>RFC5966</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC1123</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8490</doc-id>
            <doc-id>RFC9103</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7766</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7767</doc-id>
        <title>Application-Initiated Check-Pointing via the Port Control Protocol (PCP)</title>
        <author>
            <name>S. Vinapamula</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>serviceability</kw>
            <kw>SDN</kw>
            <kw>resilience</kw>
            <kw>robustness</kw>
            <kw>network programmability</kw>
            <kw>network API</kw>
            <kw>application control</kw>
            <kw>service-aware networking</kw>
            <kw>automation</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.</p><p> This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.</p></abstract>
        <draft>draft-vinapamula-flow-ha-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7768</doc-id>
        <title>Port Management to Reduce Logging in Large-Scale NATs</title>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>W. Li</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <author>
            <name>J. Huang</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete.  There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address.  One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers.  It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs.  This document suggests a way to achieve dynamic port sharing while keeping log volumes low.</p></abstract>
        <draft>draft-tsou-behave-natx4-log-reduction-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7768</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7769</doc-id>
        <title>Media Access Control (MAC) Address Withdrawal over Static Pseudowire</title>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>M. Venkatesan</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PW</kw>
            <kw>ACH</kw>
            <kw>associated channel</kw>
        </keywords>
        <abstract><p>This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH).  Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.</p></abstract>
        <draft>draft-ietf-pals-mpls-tp-mac-wd-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7770</doc-id>
        <title>Extensions to OSPF for Advertising Optional Router Capabilities</title>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>JP. Vasseur</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>S. Shaffer</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>ospfv2</kw>
            <kw>ospfv3</kw>
            <kw>open shortest path first</kw>
            <kw>ri</kw>
            <kw>router information</kw>
            <kw>lsa</kw>
            <kw>link state advertisement</kw>
        </keywords>
        <abstract><p>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain.  This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities.  The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose.  In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique LSA type function code.  In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).  This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.</p></abstract>
        <draft>draft-ietf-ospf-rfc4970bis-07</draft>
        <obsoletes>
            <doc-id>RFC4970</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7770</errata-url>
        <doi>10.17487/RFC7770</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7771</doc-id>
        <title>Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires</title>
        <author>
            <name>A. Malis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>J. Shin</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <date>
            <month>January</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>end-to-end protection</kw>
            <kw>linear protection</kw>
        </keywords>
        <abstract><p>In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection.  With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection.  However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW.  This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870.  It also contains an optional approach based on MPLS-TP Linear Protection.</p></abstract>
        <draft>draft-ietf-pals-ms-pw-protection-04</draft>
        <updates>
            <doc-id>RFC6870</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7771</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7772</doc-id>
        <title>Reducing Energy Consumption of Router Advertisements</title>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <author>
            <name>L. Colitti</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>Frequent Router Advertisement messages can severely impact host power consumption.  This document recommends operational practices to avoid such impact.</p></abstract>
        <draft>draft-ietf-v6ops-reducing-ra-energy-consumption-03</draft>
        <is-also>
            <doc-id>BCP0202</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC7772</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7773</doc-id>
        <title>Authentication Context Certificate Extension</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.</p><p> This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion Markup Language (SAML) assertion.</p></abstract>
        <draft>draft-santesson-auth-context-extension-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7773</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7774</doc-id>
        <title>Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6</title>
        <author>
            <name>Y. Doi</name>
        </author>
        <author>
            <name>M. Gillmore</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MPL</kw>
            <kw>DHCPv6</kw>
        </keywords>
        <abstract><p>This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option.  MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in an MPL Domain.  Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters.</p></abstract>
        <draft>draft-ietf-roll-mpl-parameter-configuration-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7774</errata-url>
        <doi>10.17487/RFC7774</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7775</doc-id>
        <title>IS-IS Route Preference for Extended IP and IPv6 Reachability</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>In existing specifications, the route preferences for IPv4/IPv6 Extended Reachability TLVs are not explicitly stated.  There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs).  This document addresses these issues.</p></abstract>
        <draft>draft-ietf-isis-route-preference-02</draft>
        <updates>
            <doc-id>RFC5308</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7776</doc-id>
        <title>IETF Anti-Harassment Procedures</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Ombudsman</kw>
            <kw>Ombudsperson</kw>
            <kw>Ombudsteam</kw>
        </keywords>
        <abstract><p>IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.</p><p> This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.</p></abstract>
        <draft>draft-farrresnickel-harassment-10</draft>
        <updates>
            <doc-id>RFC2418</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8716</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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7776</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7777</doc-id>
        <title>Advertising Node Administrative Tags in OSPF</title>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <author>
            <name>A. Smirnov</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>open shortest path first</kw>
        </keywords>
        <abstract><p>This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to the OSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.</p><p> This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags.</p></abstract>
        <draft>draft-ietf-ospf-node-admin-tag-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7777</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7778</doc-id>
        <title>Mobile Communication Congestion Exposure Scenario</title>
        <author>
            <name>D. Kutscher</name>
        </author>
        <author>
            <name>F. Mir</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>Y. Zhang</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>congestion exposure</kw>
            <kw>mobile communications</kw>
        </keywords>
        <abstract><p>This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS).  This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied.  Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.</p></abstract>
        <draft>draft-ietf-conex-mobile-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>conex</wg_acronym>
        <doi>10.17487/RFC7778</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7779</doc-id>
        <title>Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)</title>
        <author>
            <name>H. Rogge</name>
        </author>
        <author>
            <name>E. Baccelli</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>MANET</kw>
            <kw>metric</kw>
            <kw>ad hoc network</kw>
            <kw>routing</kw>
            <kw>IP networks</kw>
            <kw>OLSR</kw>
            <kw>ETT</kw>
            <kw>ETX</kw>
            <kw>Funkfeuer</kw>
            <kw>DAT</kw>
        </keywords>
        <abstract><p>This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).</p></abstract>
        <draft>draft-ietf-manet-olsrv2-dat-metric-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7779</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7780</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>S. Gupta</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>RBridge</kw>
            <kw>IS-IS</kw>
            <kw>reachability</kw>
            <kw>overload</kw>
            <kw>MTU</kw>
            <kw>DEI</kw>
            <kw>multicast</kw>
            <kw>RPF</kw>
            <kw>color</kw>
            <kw>E-L1FS</kw>
            <kw>purge</kw>
        </keywords>
        <abstract><p>Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates.  RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively.  This document provides other known clarifications, corrections, and updates.  It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.</p></abstract>
        <draft>draft-ietf-trill-rfc7180bis-07</draft>
        <obsoletes>
            <doc-id>RFC7180</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC6325</doc-id>
            <doc-id>RFC7177</doc-id>
            <doc-id>RFC7179</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8249</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7780</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7781</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access</title>
        <author>
            <name>H. Zhai</name>
        </author>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>virtual RBridge</kw>
            <kw>aggregation</kw>
            <kw>flip-flopping</kw>
        </keywords>
        <abstract><p>The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology.  Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379.  In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge.  Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.</p></abstract>
        <draft>draft-ietf-trill-pseudonode-nickname-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7781</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7782</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments</title>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>H. Zhai</name>
        </author>
        <author>
            <name>M. Durrani</name>
        </author>
        <author>
            <name>S. Gupta</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>LAALP</kw>
            <kw>vSwitch</kw>
            <kw>MC-LAG</kw>
            <kw>DRNI</kw>
        </keywords>
        <abstract><p>TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.</p><p> This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.</p></abstract>
        <draft>draft-ietf-trill-aa-multi-attach-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7782</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7783</doc-id>
        <title>Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <author>
            <name>J. Pathangi</name>
        </author>
        <author>
            <name>J. Hudson</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Affinity</kw>
            <kw>RPF</kw>
        </keywords>
        <abstract><p>TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs.  Appointed Forwarders provide VLAN-based load sharing with an active-standby model.  High-performance applications require an active-active load-sharing model.  The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch).  Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations.  This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues.  CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree.  This document updates RFC 6325.</p></abstract>
        <draft>draft-ietf-trill-cmt-11</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7783</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7784</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB</title>
        <author>
            <name>D. Kumar</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>T. Senevirathne</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>CFM</kw>
            <kw>MEP</kw>
            <kw>MIP</kw>
            <kw>Fault Management</kw>
        </keywords>
        <abstract><p>This document specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links).</p></abstract>
        <draft>draft-ietf-trill-oam-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7784</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7785</doc-id>
        <title>Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite</title>
        <author>
            <name>S. Vinapamula</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IPv4 service continuity</kw>
            <kw>IPv4 address exhaustion</kw>
            <kw>Service Availability</kw>
            <kw>High Availability</kw>
            <kw>Address sharing</kw>
            <kw>IPv6</kw>
            <kw>Reliability</kw>
            <kw>IPv4 over IPv6</kw>
            <kw>State migration</kw>
            <kw>Stability</kw>
            <kw>Disruption</kw>
            <kw>Privacy</kw>
        </keywords>
        <abstract><p>This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues.</p></abstract>
        <draft>draft-vinapamula-softwire-dslite-prefix-binding-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7785</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7786</doc-id>
        <title>TCP Modifications for Congestion Exposure (ConEx)</title>
        <author>
            <name>M. Kuehlewind</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Scheffenegger</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow.  This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).</p></abstract>
        <draft>draft-ietf-conex-tcp-modifications-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>conex</wg_acronym>
        <doi>10.17487/RFC7786</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7787</doc-id>
        <title>Distributed Node Consensus Protocol</title>
        <author>
            <name>M. Stenberg</name>
        </author>
        <author>
            <name>S. Barth</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Homenet</kw>
        </keywords>
        <abstract><p>This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees.  DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.</p></abstract>
        <draft>draft-ietf-homenet-dncp-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <doi>10.17487/RFC7787</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7788</doc-id>
        <title>Home Networking Control Protocol</title>
        <author>
            <name>M. Stenberg</name>
        </author>
        <author>
            <name>S. Barth</name>
        </author>
        <author>
            <name>P. Pfister</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Homenet</kw>
            <kw>DNCP</kw>
        </keywords>
        <abstract><p>This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices.  HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP).  HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.</p></abstract>
        <draft>draft-ietf-homenet-hncp-10</draft>
        <updated-by>
            <doc-id>RFC8375</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7788</errata-url>
        <doi>10.17487/RFC7788</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7789</doc-id>
        <title>Impact of BGP Filtering on Inter-Domain Routing Policies</title>
        <author>
            <name>C. Cardona</name>
        </author>
        <author>
            <name>P. Francois</name>
        </author>
        <author>
            <name>P. Lucente</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>More-specific prefix</kw>
            <kw>Less-specific prefix</kw>
            <kw>Autonomous systems</kw>
            <kw>Traffic engineering</kw>
        </keywords>
        <abstract><p>This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes.  We provide a review of the techniques to detect the occurrence of this issue and defend against it.</p></abstract>
        <draft>draft-ietf-grow-filtering-threats-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC7789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7790</doc-id>
        <title>Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)</title>
        <author>
            <name>Y. Yoneya</name>
        </author>
        <author>
            <name>T. Nemoto</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols.  Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping.  In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration.  This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols.  In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.</p></abstract>
        <draft>draft-ietf-precis-mappings-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>precis</wg_acronym>
        <doi>10.17487/RFC7790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7791</doc-id>
        <title>Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>D. Migault</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>MIF</kw>
            <kw>Load balancing</kw>
            <kw>Load sharing</kw>
            <kw>MOBIKE</kw>
        </keywords>
        <abstract><p>This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.</p><p> The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.</p></abstract>
        <draft>draft-mglt-ipsecme-clone-ike-sa-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7791</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7792</doc-id>
        <title>RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks</title>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>X. Zhang</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Flexible-grid</kw>
            <kw>Flexible optical grid</kw>
            <kw>Optical network</kw>
            <kw>Optical trail</kw>
            <kw>Optical LSP</kw>
            <kw>GMPLS</kw>
            <kw>WDM</kw>
            <kw>PCE</kw>
            <kw>spectrum reservation</kw>
            <kw>flexible spectrum</kw>
        </keywords>
        <abstract><p>This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.</p></abstract>
        <draft>draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7793</doc-id>
        <title>Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."</p><p> This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure.</p></abstract>
        <draft>draft-ietf-dnsop-rfc6598-rfc6303-05</draft>
        <is-also>
            <doc-id>BCP0163</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7794</doc-id>
        <title>IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability</title>
        <author>
            <name>L. Ginsberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>U. Chunduri</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ISIS</kw>
        </keywords>
        <abstract><p>This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.</p></abstract>
        <draft>draft-ietf-isis-prefix-attributes-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7795</doc-id>
        <title>Pseudowire Redundancy on the Switching Provider Edge (S-PE)</title>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>H. Wang</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659.  Operations of the S-PEs that provide PW redundancy are specified in this document.  Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused.  This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.</p></abstract>
        <draft>draft-ietf-pals-redundancy-spe-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7796</doc-id>
        <title>Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)</title>
        <author>
            <name>Y. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <author>
            <name>M. Paul</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Etree</kw>
        </keywords>
        <abstract><p>This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services.  A VPLS Provider Edge (PE) model is illustrated as an example for the solution.  In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute.  The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively.  A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.</p></abstract>
        <draft>draft-ietf-l2vpn-vpls-pe-etree-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7796</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7797</doc-id>
        <title>JSON Web Signature (JWS) Unencoded Payload Option</title>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>Digital Signature</kw>
            <kw>Message Authentication Code</kw>
            <kw>MAC</kw>
            <kw>Unencoded Payload</kw>
        </keywords>
        <abstract><p>JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.</p><p> This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.</p></abstract>
        <draft>draft-ietf-jose-jws-signing-input-options-09</draft>
        <updates>
            <doc-id>RFC7519</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <doi>10.17487/RFC7797</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7798</doc-id>
        <title>RTP Payload Format for High Efficiency Video Coding (HEVC)</title>
        <author>
            <name>Y.-K. Wang</name>
        </author>
        <author>
            <name>Y. Sanchez</name>
        </author>
        <author>
            <name>T. Schierl</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>M. M. Hannuksela</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>H.265</kw>
            <kw>: ISO/IEC 23008-2</kw>
            <kw>Single NAL Unit Packet</kw>
            <kw>Aggregation Packet</kw>
            <kw>Fragmentation Unit</kw>
            <kw>Payload Content Information Packet</kw>
            <kw>Use of HEVC with Feedback Messages.</kw>
        </keywords>
        <abstract><p>This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC).  The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets.  Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams.  When multiple RTP streams are used, a single transport or multiple transports may be utilized.  The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.</p></abstract>
        <draft>draft-ietf-payload-rtp-h265-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC7798</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7799</doc-id>
        <title>Active and Passive Metrics and Methods (with Hybrid Types In-Between)</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IP Performance</kw>
            <kw>Measurements</kw>
            <kw>Testing</kw>
            <kw>Network Characterization</kw>
        </keywords>
        <abstract><p>This memo provides clear definitions for Active and Passive performance assessment.  The construction of Metrics and Methods can be described as either "Active" or "Passive".  Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods".  This memo also describes multiple dimensions to help evaluate new methods as they emerge.</p></abstract>
        <draft>draft-ietf-ippm-active-passive-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7799</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7800</doc-id>
        <title>Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>Proof-of-Possession</kw>
            <kw>Holder-of-Key</kw>
        </keywords>
        <abstract><p>This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter.  Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.</p></abstract>
        <draft>draft-ietf-oauth-proof-of-possession-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7800</errata-url>
        <doi>10.17487/RFC7800</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7801</doc-id>
        <title>GOST R 34.12-2015: Block Cipher "Kuznyechik"</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Kuznyechik</kw>
            <kw>Block Cipher</kw>
        </keywords>
        <abstract><p>This document is intended to be a source of information about the Russian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik".  This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).</p></abstract>
        <draft>draft-dolmatov-kuznyechik-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7801</errata-url>
        <doi>10.17487/RFC7801</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7802</doc-id>
        <title>A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism</title>
        <author>
            <name>S. Emery</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.</p><p> This document obsoletes RFC 4402 and reclassifies that document as Historic. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations.</p></abstract>
        <draft>draft-ietf-kitten-rfc4402bis-02</draft>
        <obsoletes>
            <doc-id>RFC4402</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC7802</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7803</doc-id>
        <title>Changing the Registration Policy for the NETCONF Capability URNs Registry</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>February</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>The registration policy for the "Network Configuration Protocol (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict.  This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs.</p></abstract>
        <draft>draft-leiba-netmod-regpolicy-update-02</draft>
        <updates>
            <doc-id>RFC6241</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0203</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7803</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7804</doc-id>
        <title>Salted Challenge Response HTTP Authentication Mechanism</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>HTTPAUTH</kw>
            <kw>HTTP</kw>
            <kw>SASL</kw>
            <kw>SCRAM</kw>
            <kw>GS2</kw>
            <kw>GSSAPI</kw>
            <kw>GSS-API</kw>
        </keywords>
        <abstract><p>This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.</p></abstract>
        <draft>draft-ietf-httpauth-scram-auth-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7804</errata-url>
        <doi>10.17487/RFC7804</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7805</doc-id>
        <title>Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status</title>
        <author>
            <name>A. Zimmermann</name>
        </author>
        <author>
            <name>W. Eddy</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status.  The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013.  Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.</p></abstract>
        <draft>draft-ietf-tcpm-undeployed-03</draft>
        <obsoletes>
            <doc-id>RFC0675</doc-id>
            <doc-id>RFC0721</doc-id>
            <doc-id>RFC0761</doc-id>
            <doc-id>RFC0813</doc-id>
            <doc-id>RFC0816</doc-id>
            <doc-id>RFC0879</doc-id>
            <doc-id>RFC0896</doc-id>
            <doc-id>RFC1078</doc-id>
            <doc-id>RFC6013</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC7414</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC7805</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7806</doc-id>
        <title>On Queuing, Marking, and Dropping</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Pan</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This note discusses queuing and marking/dropping algorithms.  While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.</p></abstract>
        <draft>draft-ietf-aqm-fq-implementation-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <doi>10.17487/RFC7806</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7807</doc-id>
        <title>Problem Details for HTTP APIs</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>status</kw>
            <kw>HTTP</kw>
            <kw>error</kw>
            <kw>problem</kw>
            <kw>API</kw>
            <kw>JSON</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</p></abstract>
        <draft>draft-ietf-appsawg-http-problem-03</draft>
        <obsoleted-by>
            <doc-id>RFC9457</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7807</errata-url>
        <doi>10.17487/RFC7807</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7808</doc-id>
        <title>Time Zone Data Distribution Service</title>
        <author>
            <name>M. Douglass</name>
        </author>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>time zone</kw>
            <kw>calendaring</kw>
            <kw>scheduling</kw>
        </keywords>
        <abstract><p>This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.</p></abstract>
        <draft>draft-ietf-tzdist-service-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>tzdist</wg_acronym>
        <doi>10.17487/RFC7808</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7809</doc-id>
        <title>Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>CalDAV</kw>
            <kw>calendaring</kw>
            <kw>iCalendar</kw>
            <kw>time zone</kw>
        </keywords>
        <abstract><p>This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.</p></abstract>
        <draft>draft-ietf-tzdist-caldav-timezone-ref-05</draft>
        <updates>
            <doc-id>RFC4791</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>tzdist</wg_acronym>
        <doi>10.17487/RFC7809</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7810</doc-id>
        <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Giacalone</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</p><p> This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</p><p> Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</p></abstract>
        <draft>draft-ietf-isis-te-metric-extensions-11</draft>
        <obsoleted-by>
            <doc-id>RFC8570</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7810</errata-url>
        <doi>10.17487/RFC7810</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7811</doc-id>
        <title>An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)</title>
        <author>
            <name>G. Enyedi</name>
        </author>
        <author>
            <name>A. Csaszar</name>
        </author>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <author>
            <name>A. Gopalan</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>118</page-count>
        <keywords>
            <kw>MRT</kw>
            <kw>FRR</kw>
            <kw>LFA</kw>
            <kw>recovery</kw>
            <kw>failure</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document supports the solution put forth in "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)" (RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.</p></abstract>
        <draft>draft-ietf-rtgwg-mrt-frr-algorithm-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC7811</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7812</doc-id>
        <title>An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)</title>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <author>
            <name>G. Enyedi</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>MRT</kw>
            <kw>FRR</kw>
            <kw>LFA</kw>
            <kw>recovery</kw>
            <kw>failure</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR).  MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure.</p></abstract>
        <draft>draft-ietf-rtgwg-mrt-frr-architecture-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC7812</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7813</doc-id>
        <title>IS-IS Path Control and Reservation</title>
        <author>
            <name>J. Farkas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Bragg</name>
        </author>
        <author>
            <name>P. Unbehagen</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>P. Ashwood-Smith</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IS-IS</kw>
            <kw>SPB</kw>
        </keywords>
        <abstract><p>IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB).  IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain.  This document specifies the sub-TLVs for IS-IS PCR.</p></abstract>
        <draft>draft-ietf-isis-pcr-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7813</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7814</doc-id>
        <title>Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution</title>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>T. Boyes</name>
        </author>
        <author>
            <name>B. Fee</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Data Center Interconnect</kw>
            <kw>Data Center Network</kw>
            <kw>Virtual Machine (VM) migration</kw>
        </keywords>
        <abstract><p>This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers.</p></abstract>
        <draft>draft-ietf-bess-virtual-subnet-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7814</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7815</doc-id>
        <title>Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IPsec</kw>
            <kw>IoT</kw>
            <kw>Constrained</kw>
        </keywords>
        <abstract><p>This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.</p><p> This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.</p></abstract>
        <draft>draft-ietf-lwig-ikev2-minimal-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC7815</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7816</doc-id>
        <title>DNS Query Name Minimisation to Improve Privacy</title>
        <author>
            <name>S. Bortzmeyer</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.</p></abstract>
        <draft>draft-ietf-dnsop-qname-minimisation-09</draft>
        <obsoleted-by>
            <doc-id>RFC9156</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7816</errata-url>
        <doi>10.17487/RFC7816</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7817</doc-id>
        <title>Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>Submission</kw>
            <kw>IMAP</kw>
            <kw>POP</kw>
            <kw>ManageSieve</kw>
        </keywords>
        <abstract><p>This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients.  It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.</p></abstract>
        <draft>draft-ietf-uta-email-tls-certs-09</draft>
        <updates>
            <doc-id>RFC2595</doc-id>
            <doc-id>RFC3207</doc-id>
            <doc-id>RFC3501</doc-id>
            <doc-id>RFC5804</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <doi>10.17487/RFC7817</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7818</doc-id>
        <title>URN Namespace for MEF Documents</title>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document describes the Namespace Identifier (NID) "mef" for Uniform Resource Names (URNs) used to identify resources published by MEF Forum (https://www.mef.net).  MEF specifies and manages resources that utilize this URN identification model.  Management activities for these and other resources types are handled by the manager of the MEF Assigned Names and Numbers (MANN) registry.</p></abstract>
        <draft>draft-mahesh-mef-urn-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7819</doc-id>
        <title>Privacy Considerations for DHCP</title>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DHCP Privacy</kw>
        </keywords>
        <abstract><p>DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts.  This document discusses the various identifiers used by DHCP and the potential privacy issues.</p></abstract>
        <draft>draft-ietf-dhc-dhcp-privacy-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7820</doc-id>
        <title>UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Checksum</kw>
            <kw>UDP</kw>
            <kw>IPPM</kw>
            <kw>timestamping</kw>
        </keywords>
        <abstract><p>The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks.  Delay measurement is performed in these protocols by using timestamped test packets.  Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission.  Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification.  This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field.  The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.</p></abstract>
        <draft>draft-ietf-ippm-checksum-trailer-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC7820</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7821</doc-id>
        <title>UDP Checksum Complement in the Network Time Protocol (NTP)</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>UDP</kw>
            <kw>Checksum</kw>
            <kw>timestamping</kw>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages.  To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission.  Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification.  This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field.  The behavior defined in this document is interoperable with existing NTP implementations.</p></abstract>
        <draft>draft-ietf-ntp-checksum-trailer-07</draft>
        <updated-by>
            <doc-id>RFC9748</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC7821</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7822</doc-id>
        <title>Network Time Protocol Version 4 (NTPv4) Extension Fields</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>D. Mayer</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>extension field</kw>
        </keywords>
        <abstract><p>The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields.  An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header.  This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).</p></abstract>
        <draft>draft-ietf-ntp-extension-field-07</draft>
        <updates>
            <doc-id>RFC5905</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9748</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC7822</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7823</doc-id>
        <title>Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions</title>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>S. Giacalone</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Traffic Engineering</kw>
            <kw> Path Computation</kw>
        </keywords>
        <abstract><p>In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP).  Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load.  This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.</p></abstract>
        <draft>draft-ietf-teas-te-express-path-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7823</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7824</doc-id>
        <title>Privacy Considerations for DHCPv6</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts.  This document describes the privacy issues associated with the use of DHCPv6 by Internet users.  It is intended to be an analysis of the present situation and does not propose any solutions.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-privacy-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7824</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7825</doc-id>
        <title>A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)</title>
        <author>
            <name>J. Goldberg</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>T. Zeng</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>ICE</kw>
            <kw>Media Delivery</kw>
            <kw>RTP</kw>
            <kw>RTCP</kw>
            <kw>D-ICE</kw>
            <kw>AVP</kw>
            <kw>AVPF</kw>
            <kw>SAVP</kw>
            <kw>SAVPF</kw>
            <kw>setup.ice-d-m</kw>
            <kw>rtsp-ice-d-m</kw>
            <kw>SDP</kw>
        </keywords>
        <abstract><p>This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0).  It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.</p></abstract>
        <draft>draft-ietf-mmusic-rtsp-nat-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7826</doc-id>
        <title>Real-Time Streaming Protocol Version 2.0</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>A. Rao</name>
        </author>
        <author>
            <name>R. Lanphier</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>318</page-count>
        <keywords>
            <kw>mmusic</kw>
            <kw>RTSP</kw>
            <kw>RTSP/2.0</kw>
            <kw>real-time streaming protocol</kw>
        </keywords>
        <abstract><p>This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.</p><p> RTSP is an application-layer protocol for the setup and control of 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. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).</p></abstract>
        <draft>draft-ietf-mmusic-rfc2326bis-40</draft>
        <obsoletes>
            <doc-id>RFC2326</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7826</errata-url>
        <doi>10.17487/RFC7826</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7827</doc-id>
        <title>The Role of the IRTF Chair</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.</p></abstract>
        <draft>draft-iab-irtf-chair-description-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7827</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7828</doc-id>
        <title>The edns-tcp-keepalive EDNS0 Option</title>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>R. Bellis</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>long-lived</kw>
            <kw>dnssec</kw>
            <kw>DNS</kw>
            <kw>TCP/IP</kw>
            <kw>transport</kw>
        </keywords>
        <abstract><p>DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.</p><p> This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.</p></abstract>
        <draft>draft-ietf-dnsop-edns-tcp-keepalive-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7828</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7829</doc-id>
        <title>SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol</title>
        <author>
            <name>Y. Nishida</name>
        </author>
        <author>
            <name>P. Natarajan</name>
        </author>
        <author>
            <name>A. Caro</name>
        </author>
        <author>
            <name>P. Amer</name>
        </author>
        <author>
            <name>K. Nielsen</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>Failover</kw>
            <kw>multipath</kw>
            <kw>multihoming</kw>
            <kw>Potentially Failed</kw>
        </keywords>
        <abstract><p>The Stream Control Transmission Protocol (SCTP) supports multihoming. However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed (SCTP-PF) destination state in SCTP Path Management.</p><p> This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.</p><p> Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.</p><p> The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-failover-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC7829</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7830</doc-id>
        <title>The EDNS(0) Padding Option</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Domain Name System</kw>
            <kw>DNS</kw>
            <kw>EDNS</kw>
            <kw>EDNS0</kw>
            <kw>Security</kw>
            <kw>Encryption</kw>
            <kw>Padding</kw>
        </keywords>
        <abstract><p>This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.</p></abstract>
        <draft>draft-ietf-dprive-edns0-padding-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <doi>10.17487/RFC7830</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7831</doc-id>
        <title>Application Bridging for Federated Access Beyond Web (ABFAB) Architecture</title>
        <author>
            <name>J. Howlett</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>Federated Authentication</kw>
            <kw>AAA</kw>
            <kw>RADIUS</kw>
            <kw>Diameter</kw>
            <kw>GSS-API</kw>
            <kw>EAP</kw>
            <kw>SAML</kw>
        </keywords>
        <abstract><p>Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common.</p><p> This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including the Remote Authentication Dial-In User Service (RADIUS), the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP), and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, Relying Parties, and federations.</p></abstract>
        <draft>draft-ietf-abfab-arch-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>abfab</wg_acronym>
        <doi>10.17487/RFC7831</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7832</doc-id>
        <title>Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases</title>
        <author>
            <name>R. Smith</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Federated Authentication</kw>
            <kw>AAA</kw>
            <kw>RADIUS</kw>
            <kw>Diameter</kw>
            <kw>GSS-API</kw>
            <kw>EAP</kw>
            <kw>SASL</kw>
        </keywords>
        <abstract><p>Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web-based contexts.  The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.</p></abstract>
        <draft>draft-ietf-abfab-usecases-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>abfab</wg_acronym>
        <doi>10.17487/RFC7832</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7833</doc-id>
        <title>A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)</title>
        <author>
            <name>J. Howlett</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>A. Perez-Mendez</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>ABFAB</kw>
            <kw>AAA</kw>
            <kw>EAP</kw>
            <kw>RADIUS</kw>
            <kw>SAML</kw>
        </keywords>
        <abstract><p>This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated Access Beyond web (ABFAB) architecture.  It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods.  The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding.  The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients).  These clients may be named using a Network Access Identifier (NAI) name identifier format.  Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject.  The use of the artifacts defined in this document is not exclusive to ABFAB.  They can be applied in any Authentication, Authorization, and Accounting (AAA) scenario, such as network access control.</p></abstract>
        <draft>draft-ietf-abfab-aaa-saml-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>abfab</wg_acronym>
        <doi>10.17487/RFC7833</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7834</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Impact</title>
        <author>
            <name>D. Saucez</name>
        </author>
        <author>
            <name>L. Iannone</name>
        </author>
        <author>
            <name>A. Cabellos</name>
        </author>
        <author>
            <name>F. Coras</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping.  In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.</p></abstract>
        <draft>draft-ietf-lisp-impact-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC7834</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7835</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Threat Analysis</title>
        <author>
            <name>D. Saucez</name>
        </author>
        <author>
            <name>L. Iannone</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).</p></abstract>
        <draft>draft-ietf-lisp-threats-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC7835</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7836</doc-id>
        <title>Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012</title>
        <author>
            <name>S. Smyshlyaev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Alekseev</name>
        </author>
        <author>
            <name>I. Oshkin</name>
        </author>
        <author>
            <name>V. Popov</name>
        </author>
        <author>
            <name>S. Leontiev</name>
        </author>
        <author>
            <name>V. Podobaev</name>
        </author>
        <author>
            <name>D. Belyavsky</name>
        </author>
        <date>
            <month>March</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>HMAC</kw>
            <kw>PRF</kw>
            <kw>key agreement</kw>
            <kw>VKO</kw>
            <kw>key exchange</kw>
            <kw>key derivation</kw>
            <kw>KDF</kw>
            <kw>key tree</kw>
            <kw>elliptic curve</kw>
            <kw>Weierstrass</kw>
            <kw>twisted Edwards</kw>
            <kw>TLS</kw>
            <kw>IPsec</kw>
            <kw>IKE</kw>
            <kw>IKEv2</kw>
        </keywords>
        <abstract><p>The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.</p><p> These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.</p></abstract>
        <draft>draft-smyshlyaev-gost-usage-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7836</errata-url>
        <doi>10.17487/RFC7836</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7837</doc-id>
        <title>IPv6 Destination Option for Congestion Exposure (ConEx)</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>M. Kuehlewind</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <author>
            <name>C. Ralli</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Accountability</kw>
            <kw>Traffic Management</kw>
            <kw>Fairness</kw>
            <kw>Resource Sharing</kw>
            <kw>Congestion Control</kw>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Denial of Service</kw>
        </keywords>
        <abstract><p>Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow.  This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.</p></abstract>
        <draft>draft-ietf-conex-destopt-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>conex</wg_acronym>
        <doi>10.17487/RFC7837</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7838</doc-id>
        <title>HTTP Alternative Services</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>P. McManus</name>
        </author>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>ALPN</kw>
            <kw>Alternative Services</kw>
        </keywords>
        <abstract><p>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</p></abstract>
        <draft>draft-ietf-httpbis-alt-svc-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7838</errata-url>
        <doi>10.17487/RFC7838</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7839</doc-id>
        <title>Access-Network-Identifier Option in DHCP</title>
        <author>
            <name>S. Bhandari</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>M. Grayson</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Operator-Realm</kw>
            <kw>Access-Network-Identifier</kw>
            <kw>Access-Technology-Type</kw>
            <kw>Access-Point</kw>
            <kw>BSSID</kw>
            <kw>Operator-Identifier</kw>
            <kw>DHCPv4</kw>
            <kw>DHCPv6</kw>
            <kw>Local Mobility Anchor (LMA)</kw>
            <kw>Proxy Mobile IPv6 (PMIPv6)</kw>
            <kw>Service Set Identifier (SSID)</kw>
        </keywords>
        <abstract><p>This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options.</p></abstract>
        <draft>draft-ietf-dhc-access-network-identifier-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7839</errata-url>
        <doi>10.17487/RFC7839</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7840</doc-id>
        <title>A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>L. Liess</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Emergency</kw>
            <kw>Call</kw>
            <kw>Routing</kw>
            <kw>Location</kw>
            <kw>HELD</kw>
        </keywords>
        <abstract><p>For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information.  This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function.  Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.</p></abstract>
        <draft>draft-ietf-ecrit-held-routing-05</draft>
        <updates>
            <doc-id>RFC5985</doc-id>
            <doc-id>RFC6881</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC7840</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7841</doc-id>
        <title>RFC Streams, Headers, and Boilerplates</title>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.  This document describes them and introduces some updates to reflect current usage and requirements of RFC publication.  In particular, this updated structure is intended to communicate clearly the source of RFC creation and review.  This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.</p></abstract>
        <draft>draft-iab-rfc5741bis-02</draft>
        <obsoletes>
            <doc-id>RFC5741</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9280</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7841</errata-url>
        <doi>10.17487/RFC7841</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7842</doc-id>
        <title>Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014.  This memo captures the requirements for a set of improvements that have been identified during its initial years of community use.</p></abstract>
        <draft>draft-sparks-genarea-mailarch-improvements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7842</errata-url>
        <doi>10.17487/RFC7842</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7843</doc-id>
        <title>Port Control Protocol (PCP) Third-Party ID Option</title>
        <author>
            <name>A. Ripke</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>T. Dietz</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>R. da Silva</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>PCP</kw>
            <kw>option</kw>
            <kw>third party</kw>
            <kw>ID</kw>
        </keywords>
        <abstract><p>This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.</p><p> The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.</p></abstract>
        <draft>draft-ietf-pcp-third-party-id-option-08</draft>
        <updates>
            <doc-id>RFC6887</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>pcp</wg_acronym>
        <doi>10.17487/RFC7843</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7844</doc-id>
        <title>Anonymity Profiles for DHCP Clients</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>DHCP</kw>
            <kw>DHCPv4</kw>
            <kw>DHCPv6</kw>
            <kw>pervasive monitoring</kw>
            <kw>fingerprinting</kw>
            <kw>privacy</kw>
            <kw>Anonymity</kw>
            <kw>MAC Address Randomization</kw>
            <kw>Privacy</kw>
            <kw>Surveillance</kw>
        </keywords>
        <abstract><p>Some DHCP options carry unique identifiers.  These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses.  The anonymity profiles are designed for clients that wish to remain anonymous to the visited network.  The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.</p></abstract>
        <draft>draft-ietf-dhc-anonymity-profile-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7844</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7845</doc-id>
        <title>Ogg Encapsulation for the Opus Audio Codec</title>
        <author>
            <name>T. Terriberry</name>
        </author>
        <author>
            <name>R. Lee</name>
        </author>
        <author>
            <name>R. Giles</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>container</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract><p>This document defines the Ogg encapsulation for the Opus interactive speech and audio codec.  This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.</p></abstract>
        <draft>draft-ietf-codec-oggopus-14</draft>
        <updates>
            <doc-id>RFC5334</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8486</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>codec</wg_acronym>
        <doi>10.17487/RFC7845</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7846</doc-id>
        <title>Peer-to-Peer Streaming Tracker Protocol (PPSTP)</title>
        <author>
            <name>R. Cruz</name>
        </author>
        <author>
            <name>M. Nunes</name>
        </author>
        <author>
            <name>J. Xia</name>
        </author>
        <author>
            <name>R. Huang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Taveira</name>
        </author>
        <author>
            <name>D. Lingli</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>structured media</kw>
            <kw>peer swarms control</kw>
            <kw>live streaming</kw>
            <kw>video on demand</kw>
        </keywords>
        <abstract><p>This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers.  The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics.  The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.</p></abstract>
        <draft>draft-ietf-ppsp-base-tracker-protocol-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>ppsp</wg_acronym>
        <doi>10.17487/RFC7846</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7847</doc-id>
        <title>Logical-Interface Support for IP Hosts with Multi-Access Support</title>
        <author>
            <name>T. Melia</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gundavelli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Logical-interface</kw>
            <kw>virtual-interface</kw>
            <kw>Logical interface</kw>
        </keywords>
        <abstract><p>A logical interface is a software semantic internal to the host operating system.  This semantic is available in all popular operating systems and is used in various protocol implementations.  Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support.  This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks.  Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features.</p></abstract>
        <draft>draft-ietf-netext-logical-interface-support-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7847</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7848</doc-id>
        <title>Mark and Signed Mark Objects Mapping</title>
        <author>
            <name>G. Lozano</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Trademark Clearinghouse</kw>
            <kw>Signed Mark Data</kw>
            <kw>Signed Mark</kw>
            <kw>Mark</kw>
            <kw>SMD</kw>
        </keywords>
        <abstract><p>Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).</p><p> One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.</p><p> This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.</p></abstract>
        <draft>draft-ietf-eppext-tmch-smd-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>eppext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7848</errata-url>
        <doi>10.17487/RFC7848</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7849</doc-id>
        <title>An IPv6 Profile for 3GPP Mobile Devices</title>
        <author>
            <name>D. Binet</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>A. Vizdal</name>
        </author>
        <author>
            <name>G. Chen</name>
        </author>
        <author>
            <name>N. Heatley</name>
        </author>
        <author>
            <name>R. Chandler</name>
        </author>
        <author>
            <name>D. Michaud</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>W. Haeffner</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IPv4 service continuity</kw>
            <kw>address shortage</kw>
            <kw>address depletion</kw>
            <kw>dual-stack</kw>
            <kw>IPv6-only</kw>
            <kw>IPv6 introduction</kw>
            <kw>IPv6 transition</kw>
            <kw>IPv6 migration</kw>
            <kw>cellular networks</kw>
            <kw>mobile networks</kw>
            <kw>PLMN</kw>
            <kw>and IPv6 configuration</kw>
        </keywords>
        <abstract><p>This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" (RFC 7066).</p><p> Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.</p></abstract>
        <draft>draft-ietf-v6ops-mobile-device-profile-24</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7849</errata-url>
        <doi>10.17487/RFC7849</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7850</doc-id>
        <title>Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles</title>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods.  This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'.</p></abstract>
        <draft>draft-ietf-mmusic-proto-iana-registration-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC7850</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7851</doc-id>
        <title>Peer-to-Peer (P2P) Overlay Diagnostics</title>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>X. Jiang</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>D. Bryan</name>
        </author>
        <author>
            <name>Y. Sun</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Real-time Applications and Infrastructure</kw>
            <kw>P2PSIP Working Group</kw>
            <kw>Diagnostics</kw>
            <kw>P2P</kw>
            <kw>P2PSIP</kw>
        </keywords>
        <abstract><p>This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics.  It defines extensions to the REsource LOcation And Discovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions.  Useful diagnostic information for connection and node status monitoring is also defined.  The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics.</p></abstract>
        <draft>draft-ietf-p2psip-diagnostics-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7851</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7852</doc-id>
        <title>Additional Data Related to an Emergency Call</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>R. Marshall</name>
        </author>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>113</page-count>
        <keywords>
            <kw>Additional Call Data</kw>
            <kw>Emergency Services</kw>
            <kw>Call Information</kw>
        </keywords>
        <abstract><p>When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.</p><p> The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.</p></abstract>
        <draft>draft-ietf-ecrit-additional-data-38</draft>
        <updates>
            <doc-id>RFC6443</doc-id>
            <doc-id>RFC6881</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7852</errata-url>
        <doi>10.17487/RFC7852</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7853</doc-id>
        <title>A URN Namespace for Globus</title>
        <author>
            <name>S. Martin</name>
        </author>
        <author>
            <name>S. Tuecke</name>
        </author>
        <author>
            <name>B. McCollam</name>
        </author>
        <author>
            <name>M. Lidman</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.</p></abstract>
        <draft>draft-martin-urn-globus-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7853</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7854</doc-id>
        <title>BGP Monitoring Protocol (BMP)</title>
        <author>
            <name>J. Scudder</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Fernando</name>
        </author>
        <author>
            <name>S. Stuart</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IDR</kw>
            <kw>BGP</kw>
            <kw>GROW</kw>
            <kw>BMP</kw>
        </keywords>
        <abstract><p>This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions.  BMP is intended to provide a convenient interface for obtaining route views.  Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views.  The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting.  BMP is not suitable for use as a routing protocol.</p></abstract>
        <draft>draft-ietf-grow-bmp-17</draft>
        <updated-by>
            <doc-id>RFC8671</doc-id>
            <doc-id>RFC9069</doc-id>
            <doc-id>RFC9515</doc-id>
            <doc-id>RFC9736</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7854</errata-url>
        <doi>10.17487/RFC7854</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7855</doc-id>
        <title>Source Packet Routing in Networking (SPRING) Problem Statement and Requirements</title>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>M. Horneffer</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).</p><p> This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.</p></abstract>
        <draft>draft-ietf-spring-problem-statement-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7855</errata-url>
        <doi>10.17487/RFC7855</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7856</doc-id>
        <title>Softwire Mesh Management Information Base (MIB)</title>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>P. Wu</name>
        </author>
        <author>
            <name>M. Xu</name>
        </author>
        <author>
            <name>A. Yla-Jaaski</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>mesh</kw>
        </keywords>
        <abstract><p>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 a softwire mesh.</p></abstract>
        <draft>draft-ietf-softwire-mesh-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC7856</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7857</doc-id>
        <title>Updates to Network Address Translation (NAT) Behavioral Requirements</title>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>S. Perreault</name>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>K. Naito</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>address sharing</kw>
            <kw>IPv4 service continuity</kw>
            <kw>Carrier Grade NAT</kw>
            <kw>CGN</kw>
            <kw>LSN</kw>
            <kw>NAT traversal</kw>
            <kw>RFC4787</kw>
            <kw>RFC5382</kw>
            <kw>RFC5508</kw>
            <kw>DS-Lite</kw>
            <kw>NAT64</kw>
            <kw>Address depletion</kw>
        </keywords>
        <abstract><p>This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).</p><p> This document updates RFCs 4787, 5382, and 5508.</p></abstract>
        <draft>draft-ietf-tsvwg-behave-requirements-update-08</draft>
        <updates>
            <doc-id>RFC4787</doc-id>
            <doc-id>RFC5382</doc-id>
            <doc-id>RFC5508</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0127</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC7857</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7858</doc-id>
        <title>Specification for DNS over Transport Layer Security (TLS)</title>
        <author>
            <name>Z. Hu</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>J. Heidemann</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNS encryption</kw>
            <kw>DNS privacy</kw>
        </keywords>
        <abstract><p>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</p><p> This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</p></abstract>
        <draft>draft-ietf-dprive-dns-over-tls-09</draft>
        <updated-by>
            <doc-id>RFC8310</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7858</errata-url>
        <doi>10.17487/RFC7858</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7859</doc-id>
        <title>Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols</title>
        <author>
            <name>C. Dearlove</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Mobile Ad hoc Networking (MANET)</kw>
            <kw>MANET</kw>
            <kw>TLV</kw>
            <kw>OLSRv2</kw>
            <kw>integrity check value</kw>
            <kw>ICV</kw>
            <kw>ECCSI</kw>
            <kw>elliptic curve</kw>
            <kw>identity-based signature</kw>
            <kw>IBS</kw>
            <kw>identity-based encryption</kw>
            <kw>IBE</kw>
        </keywords>
        <abstract><p>This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444.  It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.</p></abstract>
        <draft>draft-ietf-manet-ibs-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7859</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7860</doc-id>
        <title>HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3</title>
        <author>
            <name>J. Merkle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Lochter</name>
        </author>
        <date>
            <month>April</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SNMP</kw>
            <kw>USM</kw>
            <kw>HMAC</kw>
            <kw>SHA-2</kw>
        </keywords>
        <abstract><p>This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.  It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified.</p></abstract>
        <draft>draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05</draft>
        <obsoletes>
            <doc-id>RFC7630</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC7860</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7861</doc-id>
        <title>Remote Procedure Call (RPC) Security Version 3</title>
        <author>
            <name>A. Adamson</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>RPCSEC_GSS</kw>
            <kw>ONC</kw>
            <kw>RPC</kw>
            <kw>GSS</kw>
            <kw>GSS-API</kw>
            <kw>NFS</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
            <kw>confidentiality</kw>
            <kw>encryption</kw>
            <kw>mechanism</kw>
            <kw>context</kw>
        </keywords>
        <abstract><p>This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS).  This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings.  This document updates RFC 5403.</p></abstract>
        <draft>draft-ietf-nfsv4-rpcsec-gssv3-17</draft>
        <updates>
            <doc-id>RFC5403</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7861</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7862</doc-id>
        <title>Network File System (NFS) Version 4 Minor Version 2 Protocol</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>104</page-count>
        <keywords>
            <kw>NFSv4.2</kw>
            <kw>pNFS</kw>
            <kw>Server-Side Copy</kw>
            <kw>Server-Side Clone</kw>
            <kw>Labeled NFS</kw>
        </keywords>
        <abstract><p>This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1.  Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.</p></abstract>
        <draft>draft-ietf-nfsv4-minorversion2-41</draft>
        <updated-by>
            <doc-id>RFC8178</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7862</errata-url>
        <doi>10.17487/RFC7862</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7863</doc-id>
        <title>Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>87</page-count>
        <keywords>
            <kw>NFSv4.2</kw>
            <kw>XDR</kw>
        </keywords>
        <abstract><p>This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.</p></abstract>
        <draft>draft-ietf-nfsv4-minorversion2-dot-x-41</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC7863</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7864</doc-id>
        <title>Proxy Mobile IPv6 Extensions to Support Flow Mobility</title>
        <author>
            <name>CJ. Bernardos</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>flow mobility</kw>
            <kw>NB-IFOM</kw>
            <kw>PMIPv6</kw>
            <kw>FMI</kw>
            <kw>FMA</kw>
        </keywords>
        <abstract><p>Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.</p><p> This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.</p></abstract>
        <draft>draft-ietf-netext-pmipv6-flowmob-18</draft>
        <updates>
            <doc-id>RFC5213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>netext</wg_acronym>
        <doi>10.17487/RFC7864</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7865</doc-id>
        <title>Session Initiation Protocol (SIP) Recording Metadata</title>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>P. Ravindran</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations.  In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.  The recording of a session is typically performed by sending a copy of a media stream to a recording device.  This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.</p></abstract>
        <draft>draft-ietf-siprec-metadata-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>siprec</wg_acronym>
        <doi>10.17487/RFC7865</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7866</doc-id>
        <title>Session Recording Protocol</title>
        <author>
            <name>L. Portman</name>
        </author>
        <author>
            <name>H. Lum</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Eckel</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>A. Hutton</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>siprec</kw>
        </keywords>
        <abstract><p>This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device.  The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device.  This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording.  Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document.  In addition, lawful intercept is outside the scope of this document.</p></abstract>
        <draft>draft-ietf-siprec-protocol-18</draft>
        <updated-by>
            <doc-id>RFC9806</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>siprec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7866</errata-url>
        <doi>10.17487/RFC7866</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7867</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications</title>
        <author>
            <name>R. Huang</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.</p></abstract>
        <draft>draft-ietf-xrblock-rtcp-xr-video-lc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC7867</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7868</doc-id>
        <title>Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)</title>
        <author>
            <name>D. Savage</name>
        </author>
        <author>
            <name>J. Ng</name>
        </author>
        <author>
            <name>S. Moore</name>
        </author>
        <author>
            <name>D. Slice</name>
        </author>
        <author>
            <name>P. Paluch</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <abstract><p>This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP).  EIGRP is a routing protocol based on Distance Vector technology.  The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993).  The algorithm and procedures were researched, developed, and simulated by SRI International.</p></abstract>
        <draft>draft-savage-eigrp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7868</errata-url>
        <doi>10.17487/RFC7868</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7869</doc-id>
        <title>The "vnc" URI Scheme</title>
        <author>
            <name>D. Warden</name>
        </author>
        <author>
            <name>I. Iordanov</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>RFB</kw>
            <kw>Remote Framebuffer</kw>
            <kw>Virtual Network Computing</kw>
        </keywords>
        <abstract><p>Virtual Network Computing (VNC) software provides remote desktop functionality.  This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications.  The scheme specifies parameters useful in securely connecting clients with remote hosts.</p></abstract>
        <draft>draft-warden-appsawg-vnc-scheme-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7869</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7870</doc-id>
        <title>Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)</title>
        <author>
            <name>Y. Fu</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>Y. Chen</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>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 managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).</p></abstract>
        <draft>draft-ietf-softwire-dslite-mib-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC7870</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7871</doc-id>
        <title>Client Subnet in DNS Queries</title>
        <author>
            <name>C. Contavalli</name>
        </author>
        <author>
            <name>W. van der Gaast</name>
        </author>
        <author>
            <name>D. Lawrence</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>edns-client-subnet</kw>
            <kw>ECS</kw>
            <kw>DNS geolocation</kw>
            <kw>DNS load-balancing</kw>
            <kw>EDNS</kw>
            <kw>EDNS0</kw>
            <kw>geolocation</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached.  Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.</p></abstract>
        <draft>draft-ietf-dnsop-edns-client-subnet-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7871</errata-url>
        <doi>10.17487/RFC7871</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7872</doc-id>
        <title>Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>packet drops</kw>
        </keywords>
        <abstract><p>This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs.  The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time.  This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-ehs-in-real-world-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7872</errata-url>
        <doi>10.17487/RFC7872</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7873</doc-id>
        <title>Domain Name System (DNS) Cookies</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Andrews</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>denial of service</kw>
            <kw>forgery</kw>
            <kw>cache poisoning</kw>
            <kw>off-path</kw>
        </keywords>
        <abstract><p>DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers.  DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)</p></abstract>
        <draft>draft-ietf-dnsop-cookies-10</draft>
        <updated-by>
            <doc-id>RFC9018</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC7873</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7874</doc-id>
        <title>WebRTC Audio Codec and Processing Requirements</title>
        <author>
            <name>JM. Valin</name>
        </author>
        <author>
            <name>C. Bran</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document outlines the audio codec and processing requirements for WebRTC endpoints.</p></abstract>
        <draft>draft-ietf-rtcweb-audio-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC7874</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7875</doc-id>
        <title>Additional WebRTC Audio Codecs for Interoperability</title>
        <author>
            <name>S. Proust</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>WebRTC</kw>
            <kw>audio</kw>
            <kw>codec</kw>
            <kw>G.722</kw>
            <kw>AMR</kw>
            <kw>AMR-WB</kw>
        </keywords>
        <abstract><p>To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.</p><p> This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.</p></abstract>
        <draft>draft-ietf-rtcweb-audio-codecs-for-interop-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC7875</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7876</doc-id>
        <title>UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>S. Soni</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MPLS</kw>
        </keywords>
        <abstract><p>RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM).  This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.</p></abstract>
        <draft>draft-ietf-mpls-rfc6374-udp-return-path-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC7876</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7877</doc-id>
        <title>Session Peering Provisioning Framework (SPPF)</title>
        <author>
            <name>K. Cartwright</name>
        </author>
        <author>
            <name>V. Bhatia</name>
        </author>
        <author>
            <name>S. Ali</name>
        </author>
        <author>
            <name>D. Schwartz</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>SPPP</kw>
            <kw>SIP</kw>
            <kw>Peering</kw>
            <kw>SED</kw>
            <kw>Provisioning</kw>
        </keywords>
        <abstract><p>This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider (SSP) data stores.  The framework is called the "Session Peering Provisioning Framework" (SPPF).  The provisioned data is typically used by network elements for session establishment.</p></abstract>
        <draft>draft-ietf-drinks-spp-framework-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>drinks</wg_acronym>
        <doi>10.17487/RFC7877</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7878</doc-id>
        <title>Session Peering Provisioning (SPP) Protocol over SOAP</title>
        <author>
            <name>K. Cartwright</name>
        </author>
        <author>
            <name>V. Bhatia</name>
        </author>
        <author>
            <name>J-F. Mule</name>
        </author>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>83</page-count>
        <keywords>
            <kw>SPPP</kw>
            <kw>SIP</kw>
            <kw>Peering</kw>
            <kw>SED</kw>
            <kw>Provisioning</kw>
        </keywords>
        <abstract><p>The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider data stores.  To utilize this framework, one needs a substrate protocol.  Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF.  The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an \%SPPF- based protocol.</p></abstract>
        <draft>draft-ietf-drinks-spp-protocol-over-soap-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>drinks</wg_acronym>
        <doi>10.17487/RFC7878</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7879</doc-id>
        <title>DTLS-SRTP Handling in SIP Back-to-Back User Agents</title>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <author>
            <name>P. Ravindran</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Session Initiation Protocol</kw>
            <kw>B2BUA</kw>
            <kw>Secure Real-time Transport</kw>
            <kw>Datagram Transport Layer Security</kw>
        </keywords>
        <abstract><p>Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints.  This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.</p></abstract>
        <draft>draft-ietf-straw-b2bua-dtls-srtp-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>straw</wg_acronym>
        <doi>10.17487/RFC7879</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7880</doc-id>
        <title>Seamless Bidirectional Forwarding Detection (S-BFD)</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>S. Pallagatti</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>seamless BFD</kw>
            <kw>negotiation free</kw>
            <kw>segment routing</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.</p><p> This document updates RFC 5880.</p></abstract>
        <draft>draft-ietf-bfd-seamless-base-11</draft>
        <updates>
            <doc-id>RFC5880</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7880</errata-url>
        <doi>10.17487/RFC7880</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7881</doc-id>
        <title>Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>seamless BFD</kw>
            <kw>negotiation free</kw>
            <kw>label verification</kw>
            <kw>segment routing</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.</p></abstract>
        <draft>draft-ietf-bfd-seamless-ip-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC7881</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7882</doc-id>
        <title>Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases</title>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>N. Kumar</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>seamless BFD</kw>
            <kw>negotiation free</kw>
            <kw>label verification</kw>
            <kw>segment routing</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.</p><p> These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.</p></abstract>
        <draft>draft-ietf-bfd-seamless-use-case-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC7882</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7883</doc-id>
        <title>Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.</p></abstract>
        <draft>draft-ietf-isis-sbfd-discriminator-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7883</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7884</doc-id>
        <title>OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators</title>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>T. Ranganath</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>seamless BFD</kw>
            <kw>negotiation free</kw>
            <kw>label verification</kw>
            <kw>segment routing</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values associated with a target network identifier.  This mechanism is applicable to both OSPFv2 and OSPFv3.</p></abstract>
        <draft>draft-ietf-ospf-sbfd-discriminator-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7884</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7885</doc-id>
        <title>Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)</title>
        <author>
            <name>V. Govindan</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RFC5885</kw>
            <kw>L2TPv3</kw>
            <kw>VCCV</kw>
            <kw>S-BFD</kw>
        </keywords>
        <abstract><p>This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV).</p><p> This document updates RFC 5885 by extending the CV Type values and the capability selection.</p></abstract>
        <draft>draft-ietf-pals-seamless-vccv-03</draft>
        <updates>
            <doc-id>RFC5885</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7885</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7886</doc-id>
        <title>Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3)</title>
        <author>
            <name>V. Govindan</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>S-BFD</kw>
        </keywords>
        <abstract><p>This document defines a new Attribute-Value Pair (AVP) that allows L2TP Control Connection Endpoints (LCCEs) to advertise one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3).</p></abstract>
        <draft>draft-ietf-l2tpext-sbfd-discriminator-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC7886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7887</doc-id>
        <title>Hierarchical Join/Prune Attributes</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>J. Arango</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>pim</kw>
        </keywords>
        <abstract><p>This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message.  This document updates RFC 5384 by renaming the encoding type registry specified there.</p></abstract>
        <draft>draft-ietf-pim-hierarchicaljoinattr-08</draft>
        <updates>
            <doc-id>RFC5384</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC7887</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7888</doc-id>
        <title>IMAP4 Non-synchronizing Literals</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>LITERAL+</kw>
            <kw>LITERAL-</kw>
            <kw>APPENDLIMIT</kw>
        </keywords>
        <abstract><p>The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP 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 that does not require this network round trip.</p><p> This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.</p><p> This document obsoletes RFC 2088.</p></abstract>
        <draft>draft-ietf-imapapnd-rfc2088bis-04</draft>
        <obsoletes>
            <doc-id>RFC2088</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>imapapnd</wg_acronym>
        <doi>10.17487/RFC7888</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7889</doc-id>
        <title>The IMAP APPENDLIMIT Extension</title>
        <author>
            <name>J. SrimushnamBoovaraghamoorthy</name>
        </author>
        <author>
            <name>N. Bisht</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.</p></abstract>
        <draft>draft-ietf-imapapnd-appendlimit-extension-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>imapapnd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7889</errata-url>
        <doi>10.17487/RFC7889</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7890</doc-id>
        <title>Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)</title>
        <author>
            <name>D. Bryan</name>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <author>
            <name>E. Shim</name>
        </author>
        <author>
            <name>D. Willis</name>
        </author>
        <author>
            <name>S. Dawkins</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Distributed Database</kw>
            <kw>P2PSIP</kw>
            <kw>SIP</kw>
            <kw>Server-less</kw>
            <kw>DHT</kw>
        </keywords>
        <abstract><p>This document defines concepts and terminology for using the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism.  These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties.  This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group.</p></abstract>
        <draft>draft-ietf-p2psip-concepts-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7890</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7891</doc-id>
        <title>Explicit Reverse Path Forwarding (RPF) Vector</title>
        <author>
            <name>J. Asghar</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Krishnaswamy</name>
        </author>
        <author>
            <name>A. Karan</name>
        </author>
        <author>
            <name>V. Arya</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Path diversity</kw>
            <kw>MoFRR</kw>
            <kw>Maximally redundant paths</kw>
        </keywords>
        <abstract><p>The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.</p><p> This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.</p></abstract>
        <draft>draft-ietf-pim-explicit-rpf-vector-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC7891</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7892</doc-id>
        <title>IANA Allocation Procedures for the GMPLS OTN Signal Type Registry</title>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>A. Bonfanti</name>
        </author>
        <author>
            <name>M. Hartley</name>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <date>
            <month>May</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>IANA defined the "OTN Signal Type" subregistry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139.  This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required.</p></abstract>
        <draft>draft-ietf-ccamp-otn-signal-type-subregistry-05</draft>
        <updates>
            <doc-id>RFC7139</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7892</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7893</doc-id>
        <title>Pseudowire Congestion Considerations</title>
        <author>
            <name>Y(J) Stein</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>pseudowire</kw>
            <kw>congestion</kw>
            <kw>TCP friendliness</kw>
        </keywords>
        <abstract><p>Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows.  Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion.  We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms.  For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow.  For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound.  Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow.  If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.</p></abstract>
        <draft>draft-ietf-pals-congcons-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7893</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7894</doc-id>
        <title>Alternative Challenge Password Attributes for Enrollment over Secure Transport</title>
        <author>
            <name>M. Pritikin</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Enrollment over Secure Transport</kw>
        </keywords>
        <abstract><p>This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol.  These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS #9: Selected Object Classes and Attribute Types Version 2.0" (RFC 2985).  Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity.</p></abstract>
        <draft>draft-wallace-est-alt-challenge-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7894</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7895</doc-id>
        <title>YANG Module Library</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server).  Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.</p></abstract>
        <draft>draft-ietf-netconf-yang-library-06</draft>
        <obsoleted-by>
            <doc-id>RFC8525</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC7895</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7896</doc-id>
        <title>Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>PCEP</kw>
            <kw>PCE</kw>
            <kw>IRO</kw>
        </keywords>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.</p><p> This document updates RFC 5440 regarding the IRO specification.</p></abstract>
        <draft>draft-ietf-pce-iro-update-07</draft>
        <updates>
            <doc-id>RFC5440</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7896</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7897</doc-id>
        <title>Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>U. Palle</name>
        </author>
        <author>
            <name>R. Casellas</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>PCEP</kw>
            <kw>PCE</kw>
            <kw>domain</kw>
            <kw>subobjects</kw>
        </keywords>
        <abstract><p>The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement.  In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS).  This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains.  This document also defines new subobjects to be used to encode domain identifiers.</p></abstract>
        <draft>draft-ietf-pce-pcep-domain-sequence-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC7897</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7898</doc-id>
        <title>Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>U. Palle</name>
        </author>
        <author>
            <name>V. Kondreddy</name>
        </author>
        <author>
            <name>R. Casellas</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>RSVP-TE</kw>
            <kw>domain</kw>
            <kw>subobjects</kw>
        </keywords>
        <abstract><p>The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.</p><p> This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.</p></abstract>
        <draft>draft-ietf-teas-rsvp-te-domain-subobjects-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7898</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7899</doc-id>
        <title>Multicast VPN State Damping</title>
        <author>
            <name>T. Morin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>R. Kebler</name>
        </author>
        <author>
            <name>J. Haas</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>dampening</kw>
            <kw>multicast</kw>
            <kw>vpn</kw>
            <kw>damping</kw>
            <kw>bgp</kw>
            <kw>pim</kw>
        </keywords>
        <abstract><p>This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites.  The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure.  The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.</p></abstract>
        <draft>draft-ietf-bess-multicast-damping-06</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7899</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7900</doc-id>
        <title>Extranet Multicast in BGP/IP MPLS VPNs</title>
        <author>
            <name>Y. Rekhter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>T. Morin</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network).  However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN.  This is known as a "Multicast VPN (MVPN) extranet".  This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.</p></abstract>
        <draft>draft-ietf-bess-mvpn-extranet-07</draft>
        <updates>
            <doc-id>RFC6513</doc-id>
            <doc-id>RFC6514</doc-id>
            <doc-id>RFC6625</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8534</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7900</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7901</doc-id>
        <title>CHAIN Query Requests in DNS</title>
        <author>
            <name>P. Wouters</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>EDNS0</kw>
            <kw>latency</kw>
        </keywords>
        <abstract><p>This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer.  The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once.  This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.</p></abstract>
        <draft>draft-ietf-dnsop-edns-chain-query-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7901</errata-url>
        <doi>10.17487/RFC7901</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7902</doc-id>
        <title>Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>T. Morin</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute.  The attribute contains a one-octet "Flags" field.  The purpose of this document is to establish an IANA registry for the assignment of the bits in this field.  Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI) Tunnel" attribute.  This document updates RFC 6514.</p></abstract>
        <draft>draft-ietf-bess-pta-flags-03</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7902</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7903</doc-id>
        <title>Windows Image Media Types</title>
        <author>
            <name>S. Leonard</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats.  Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.</p></abstract>
        <draft>draft-seantek-windows-image-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7903</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7904</doc-id>
        <title>A SIP Usage for REsource LOcation And Discovery (RELOAD)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>B. Lowekamp</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>S. Baset</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>T. Schmidt</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>p2psip</kw>
            <kw>p2p</kw>
            <kw>sip</kw>
            <kw>reload</kw>
            <kw>peer-to-peer</kw>
            <kw>session initiation</kw>
            <kw>distributed session management</kw>
            <kw>overlay network</kw>
            <kw>SIP registrar</kw>
        </keywords>
        <abstract><p>This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD).  The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay.  It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay.  After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.</p></abstract>
        <draft>draft-ietf-p2psip-sip-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC7904</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7905</doc-id>
        <title>ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)</title>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>W. Chang</name>
        </author>
        <author>
            <name>N. Mavrogiannopoulos</name>
        </author>
        <author>
            <name>J. Strombergson</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>AEAD</kw>
            <kw>DTLS</kw>
        </keywords>
        <abstract><p>This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.</p><p> This document updates RFCs 5246 and 6347.</p></abstract>
        <draft>draft-ietf-tls-chacha20-poly1305-04</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC6347</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7905</errata-url>
        <doi>10.17487/RFC7905</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7906</doc-id>
        <title>NSA's Cryptographic Message Syntax (CMS) Key Management Attributes</title>
        <author>
            <name>P. Timmel</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <abstract><p>This document defines key management attributes used by the National Security Agency (NSA).  The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages.  Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.</p></abstract>
        <draft>draft-turner-km-attributes-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7906</errata-url>
        <doi>10.17487/RFC7906</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC7907</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC7908</doc-id>
        <title>Problem Definition and Classification of BGP Route Leaks</title>
        <author>
            <name>K. Sriram</name>
        </author>
        <author>
            <name>D. Montgomery</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>E. Osterweil</name>
        </author>
        <author>
            <name>B. Dickson</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>BGPSEC</kw>
            <kw>Route Leak</kw>
            <kw>Route Leak Detection</kw>
            <kw>Route Leak Mitigation</kw>
            <kw>BGP Security</kw>
        </keywords>
        <abstract><p>A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years.  Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking.  This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention.  Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet.  The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.</p></abstract>
        <draft>draft-ietf-grow-route-leak-problem-definition-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC7908</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7909</doc-id>
        <title>Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures</title>
        <author>
            <name>R. Kisteleki</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures.  This allows relying parties to detect accidental or malicious modifications of such objects.  It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects.  This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.</p></abstract>
        <draft>draft-ietf-sidr-rpsl-sig-12</draft>
        <updates>
            <doc-id>RFC2622</doc-id>
            <doc-id>RFC4012</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC7909</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7910</doc-id>
        <title>Interoperability between the Virtual Router Redundancy Protocol and PIM</title>
        <author>
            <name>W. Zhou</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the Virtual Router Redundancy Protocol (VRRP).  It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled.  The mechanism described in this document is based on Cisco IOS software implementation.</p></abstract>
        <draft>draft-zhou-pim-vrrp-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7910</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7911</doc-id>
        <title>Advertisement of Multiple Paths in BGP</title>
        <author>
            <name>D. Walton</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract><p>This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones.  The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.</p></abstract>
        <draft>draft-ietf-idr-add-paths-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7911</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7912</doc-id>
        <title>Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>MMHS</kw>
            <kw>S/MIME</kw>
            <kw>MIXER</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field.  The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.</p></abstract>
        <draft>draft-melnikov-mmhs-authorizing-users-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7912</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7913</doc-id>
        <title>P-Access-Network-Info ABNF Update</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Transport</kw>
            <kw>PANI</kw>
            <kw>ABNF</kw>
            <kw>P-Access-Network-Info</kw>
            <kw>3GPP</kw>
            <kw>IMS</kw>
        </keywords>
        <abstract><p>This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai-3gpp'.  The values are defined in the ABNF but are not included in the list.</p></abstract>
        <draft>draft-holmberg-dispatch-pani-abnf-03</draft>
        <updates>
            <doc-id>RFC7315</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7913</errata-url>
        <doi>10.17487/RFC7913</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7914</doc-id>
        <title>The scrypt Password-Based Key Derivation Function</title>
        <author>
            <name>C. Percival</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PBKDF</kw>
        </keywords>
        <abstract><p>This document specifies the password-based key derivation function scrypt.  The function derives one or more secret keys from a secret string.  It is based on memory-hard functions, which offer added protection against attacks using custom hardware.  The document also provides an ASN.1 schema.</p></abstract>
        <draft>draft-josefsson-scrypt-kdf-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7914</errata-url>
        <doi>10.17487/RFC7914</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7915</doc-id>
        <title>IP/ICMP Translation Algorithm</title>
        <author>
            <name>C. Bao</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>T. Anderson</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>SIIT</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>control</kw>
            <kw>message</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>Stateless IP/ICMP Translation Algorithm</kw>
            <kw>RFC6145bis</kw>
        </keywords>
        <abstract><p>This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers).  This document obsoletes RFC 6145.</p></abstract>
        <draft>draft-bao-v6ops-rfc6145bis-07</draft>
        <obsoletes>
            <doc-id>RFC6145</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7915</errata-url>
        <doi>10.17487/RFC7915</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7916</doc-id>
        <title>Operational Management of Loop-Free Alternates</title>
        <author>
            <name>S. Litkowski</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>M. Horneffer</name>
        </author>
        <author>
            <name>P. Sarkar</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>LFA</kw>
            <kw>policy</kw>
            <kw>FRR</kw>
            <kw>fast reroute</kw>
            <kw>network planning</kw>
        </keywords>
        <abstract><p>Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.</p><p> This proposal is also applicable to remote-LFA solutions.</p></abstract>
        <draft>draft-ietf-rtgwg-lfa-manageability-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC7916</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7917</doc-id>
        <title>Advertising Node Administrative Tags in IS-IS</title>
        <author>
            <name>P. Sarkar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>IS-IS</kw>
            <kw>Admin-Tag</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>This document describes an extension to the IS-IS routing protocol to advertise node administrative tags.  This optional capability allows tagging and grouping of the nodes in an IS-IS domain.  The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability.  Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.</p></abstract>
        <draft>draft-ietf-isis-node-admin-tag-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7917</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7918</doc-id>
        <title>Transport Layer Security (TLS) False Start</title>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>N. Modadugu</name>
        </author>
        <author>
            <name>B. Moeller</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start".  It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally.  A TLS False Start reduces handshake latency to one round trip.</p></abstract>
        <draft>draft-ietf-tls-falsestart-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC7918</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7919</doc-id>
        <title>Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)</title>
        <author>
            <name>D. Gillmor</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Diffie-Hellman</kw>
            <kw>Discrete Logarithm</kw>
            <kw>Finite Field</kw>
            <kw>Transport Layer Security</kw>
            <kw>TLS</kw>
            <kw>Negotiation</kw>
        </keywords>
        <abstract><p>Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.</p><p> This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).</p></abstract>
        <draft>draft-ietf-tls-negotiated-ff-dhe-10</draft>
        <updates>
            <doc-id>RFC2246</doc-id>
            <doc-id>RFC4346</doc-id>
            <doc-id>RFC4492</doc-id>
            <doc-id>RFC5246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7919</errata-url>
        <doi>10.17487/RFC7919</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7920</doc-id>
        <title>Problem Statement for the Interface to the Routing System</title>
        <author>
            <name>A. Atlas</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.</p><p> This document proposes meeting this need via an Interface to the Routing System (I2RS).</p></abstract>
        <draft>draft-ietf-i2rs-problem-statement-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC7920</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7921</doc-id>
        <title>An Architecture for the Interface to the Routing System</title>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <abstract><p>This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system.  It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).</p></abstract>
        <draft>draft-ietf-i2rs-architecture-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC7921</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7922</doc-id>
        <title>Interface to the Routing System (I2RS) Traceability: Framework and Information Model</title>
        <author>
            <name>J. Clarke</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>I2RS</kw>
            <kw>I2RS Traceability</kw>
            <kw>I2RS Traceability</kw>
        </keywords>
        <abstract><p>This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework.  It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol.  This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when.  It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.</p></abstract>
        <draft>draft-ietf-i2rs-traceability-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC7922</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7923</doc-id>
        <title>Requirements for Subscription to YANG Datastores</title>
        <author>
            <name>E. Voit</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>A. Gonzalez Prieto</name>
        </author>
        <date>
            <month>June</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>pub/sub</kw>
            <kw>push updates</kw>
        </keywords>
        <abstract><p>This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore.  Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients.  Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF).  Such a service can be summarized as a "pub/sub" service for YANG datastore updates.  Beyond a set of basic requirements for the service, various refinements are addressed.  These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.</p></abstract>
        <draft>draft-ietf-i2rs-pub-sub-requirements-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC7923</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7924</doc-id>
        <title>Transport Layer Security (TLS) Cached Information Extension</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TLS Cached Information</kw>
            <kw>TLS Cached Info</kw>
            <kw>TLS Extension</kw>
            <kw>TLS Optimization</kw>
        </keywords>
        <abstract><p>Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).</p><p> This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.</p></abstract>
        <draft>draft-ietf-tls-cached-info-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC7924</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7925</doc-id>
        <title>Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things</title>
        <author>
            <name>H. Tschofenig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>Internet of Things Security</kw>
            <kw>TLS Profile</kw>
            <kw>DTLS Profile</kw>
            <kw>IoT Security</kw>
            <kw>DTLS over SMS</kw>
        </keywords>
        <abstract><p>A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.</p><p> This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.</p></abstract>
        <draft>draft-ietf-dice-profile-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dice</wg_acronym>
        <doi>10.17487/RFC7925</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7926</doc-id>
        <title>Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>X. Zhang</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>Abstract link</kw>
            <kw>Abstract node</kw>
            <kw>Abstraction</kw>
            <kw>Abstraction layer</kw>
            <kw>Aggregation</kw>
            <kw>Virtual node</kw>
            <kw>Virtual link</kw>
        </keywords>
        <abstract><p>In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.</p><p> In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.</p><p> This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.</p></abstract>
        <draft>draft-ietf-teas-interconnected-te-info-exchange-07</draft>
        <is-also>
            <doc-id>BCP0206</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC7926</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7927</doc-id>
        <title>Information-Centric Networking (ICN) Research Challenges</title>
        <author>
            <name>D. Kutscher</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Eum</name>
        </author>
        <author>
            <name>K. Pentikousis</name>
        </author>
        <author>
            <name>I. Psaras</name>
        </author>
        <author>
            <name>D. Corujo</name>
        </author>
        <author>
            <name>D. Saucez</name>
        </author>
        <author>
            <name>T. Schmidt</name>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>Information centric networking</kw>
        </keywords>
        <abstract><p>This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.</p><p> This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-challenges-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7927</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7928</doc-id>
        <title>Characterization Guidelines for Active Queue Management (AQM)</title>
        <author>
            <name>N. Kuhn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Natarajan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Khademi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Ros</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>Unmanaged large buffers in today's networks have given rise to a slew of performance issues.  These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing.  This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.</p></abstract>
        <draft>draft-ietf-aqm-eval-guidelines-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <doi>10.17487/RFC7928</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7929</doc-id>
        <title>DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP</title>
        <author>
            <name>P. Wouters</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>opportunistic security</kw>
            <kw>encrypted email</kw>
        </keywords>
        <abstract><p>OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys.  DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS.  This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record.  Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification.  The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.</p></abstract>
        <draft>draft-ietf-dane-openpgpkey-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7929</errata-url>
        <doi>10.17487/RFC7929</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7930</doc-id>
        <title>Larger Packets for RADIUS over TCP</title>
        <author>
            <name>S. Hartman</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>ABFAB</kw>
        </keywords>
        <abstract><p>The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic.  This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets.  This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information.  This document registers a new RADIUS code, an action that required IESG approval.</p></abstract>
        <draft>draft-ietf-radext-bigger-packets-07</draft>
        <updates>
            <doc-id>RFC6613</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC7930</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7931</doc-id>
        <title>NFSv4.0 Migration: Specification Update</title>
        <author>
            <name>D. Noveck</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Shivam</name>
        </author>
        <author>
            <name>C. Lever</name>
        </author>
        <author>
            <name>B. Baker</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <abstract><p>The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients.  Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0.  This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.</p></abstract>
        <draft>draft-ietf-nfsv4-rfc3530-migration-update-08</draft>
        <updates>
            <doc-id>RFC7530</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7931</errata-url>
        <doi>10.17487/RFC7931</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7932</doc-id>
        <title>Brotli Compressed Data Format</title>
        <author>
            <name>J. Alakuijala</name>
        </author>
        <author>
            <name>Z. Szabadka</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>128</page-count>
        <abstract><p>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.</p></abstract>
        <draft>draft-alakuijala-brotli-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7932</errata-url>
        <doi>10.17487/RFC7932</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7933</doc-id>
        <title>Adaptive Video Streaming over Information-Centric Networking (ICN)</title>
        <author>
            <name>C. Westphal</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Lederer</name>
        </author>
        <author>
            <name>D. Posch</name>
        </author>
        <author>
            <name>C. Timmerer</name>
        </author>
        <author>
            <name>A. Azgin</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <author>
            <name>C. Mueller</name>
        </author>
        <author>
            <name>A. Detti</name>
        </author>
        <author>
            <name>D. Corujo</name>
        </author>
        <author>
            <name>J. Wang</name>
        </author>
        <author>
            <name>M. Montpetit</name>
        </author>
        <author>
            <name>N. Murray</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>ICN</kw>
            <kw>CCN</kw>
            <kw>NDN</kw>
            <kw>DASH</kw>
            <kw>adaptive video streaming</kw>
            <kw>scalable video streaming</kw>
            <kw>IPTV</kw>
            <kw>P2P</kw>
            <kw>DRM</kw>
        </keywords>
        <abstract><p>This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Networking (ICN) architecture on video distribution.  As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms.  Several important topics related to video distribution over ICN are presented.  The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN.  Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.</p></abstract>
        <draft>draft-irtf-icnrg-videostreaming-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7933</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7934</doc-id>
        <title>Host Address Availability Recommendations</title>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IPv4</kw>
            <kw>SLAAC</kw>
            <kw>DHCPv6</kw>
            <kw>Prefix Delegation</kw>
            <kw>NAT</kw>
            <kw>NAT64</kw>
            <kw>464XLAT</kw>
            <kw>/64</kw>
            <kw>Address Assignment</kw>
            <kw>Addressing</kw>
        </keywords>
        <abstract><p>This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.</p></abstract>
        <draft>draft-ietf-v6ops-host-addr-availability-07</draft>
        <is-also>
            <doc-id>BCP0204</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7934</errata-url>
        <doi>10.17487/RFC7934</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7935</doc-id>
        <title>The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>G. Michaelson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.</p></abstract>
        <draft>draft-ietf-sidr-rfc6485bis-05</draft>
        <obsoletes>
            <doc-id>RFC6485</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8208</doc-id>
            <doc-id>RFC8608</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7935</errata-url>
        <doi>10.17487/RFC7935</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7936</doc-id>
        <title>Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.</p></abstract>
        <draft>draft-hardie-rfc6455-iana-clarification-03</draft>
        <updates>
            <doc-id>RFC6455</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7936</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7937</doc-id>
        <title>Content Distribution Network Interconnection (CDNI) Logging Interface</title>
        <author>
            <name>F. Le Faucheur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Bertrand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Oprescu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Peterkofsky</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>CDNI</kw>
            <kw>Logging</kw>
            <kw>CDN</kw>
            <kw>Interconnection</kw>
        </keywords>
        <abstract><p>This memo specifies the Logging interface between a downstream Content Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework.  First, it describes a reference model for CDNI logging.  Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.</p></abstract>
        <draft>draft-ietf-cdni-logging-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC7937</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7938</doc-id>
        <title>Use of BGP for Routing in Large-Scale Data Centers</title>
        <author>
            <name>P. Lapukhov</name>
        </author>
        <author>
            <name>A. Premji</name>
        </author>
        <author>
            <name>J. Mitchell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>ECMP</kw>
            <kw> Clos</kw>
        </keywords>
        <abstract><p>Some network operators build and operate data centers that support over one hundred thousand servers.  In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures.  Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability.  This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol.  The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.</p></abstract>
        <draft>draft-ietf-rtgwg-bgp-routing-large-dc-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7938</errata-url>
        <doi>10.17487/RFC7938</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7939</doc-id>
        <title>Definition of Managed Objects for the Neighborhood Discovery Protocol</title>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>I. Chakeres</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
            <kw>Routing</kw>
            <kw>Neighbor Discovery</kw>
            <kw>MANET</kw>
            <kw>NHDP-MIB</kw>
        </keywords>
        <abstract><p>This document replaces RFC 6779; it contains revisions and extensions to the original document.  It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router.  The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466.  The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP.  This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.</p></abstract>
        <draft>draft-ietf-manet-rfc6779bis-07</draft>
        <obsoletes>
            <doc-id>RFC6779</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7939</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7940</doc-id>
        <title>Representing Label Generation Rulesets Using XML</title>
        <author>
            <name>K. Davies</name>
        </author>
        <author>
            <name>A. Freytag</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>IDN</kw>
            <kw>LGR</kw>
            <kw>IDN table</kw>
            <kw>variant table</kw>
        </keywords>
        <abstract><p>This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML).  These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example.  The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.</p></abstract>
        <draft>draft-ietf-lager-specification-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>lager</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7940</errata-url>
        <doi>10.17487/RFC7940</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7941</doc-id>
        <title>RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>B. Burman</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>M. Zanaty</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP).  In some cases, it can be beneficial to speed up the delivery of these items.  The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items.  To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.</p></abstract>
        <draft>draft-ietf-avtext-sdes-hdr-ext-07</draft>
        <updated-by>
            <doc-id>RFC8843</doc-id>
            <doc-id>RFC9143</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC7941</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7942</doc-id>
        <title>Improving Awareness of Running Code: The Implementation Status Section</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>July</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</p><p> This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.</p></abstract>
        <draft>draft-sheffer-rfc6982bis-03</draft>
        <obsoletes>
            <doc-id>RFC6982</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0205</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7942</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7943</doc-id>
        <title>A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>security</kw>
            <kw>privacy</kw>
            <kw>resiliency</kw>
            <kw>attack</kw>
            <kw>scanning</kw>
            <kw>tracking</kw>
        </keywords>
        <abstract><p>This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients.  This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications.  The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.</p></abstract>
        <draft>draft-gont-dhcpv6-stable-privacy-addresses-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7943</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7944</doc-id>
        <title>Diameter Routing Message Priority</title>
        <author>
            <name>S. Donovan</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>Overload</kw>
        </keywords>
        <abstract><p>When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages.  This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions.  With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.</p></abstract>
        <draft>draft-ietf-dime-drmp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7944</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7945</doc-id>
        <title>Information-Centric Networking: Evaluation and Security Considerations</title>
        <author>
            <name>K. Pentikousis</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Ohlman</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>S. Spirou</name>
        </author>
        <author>
            <name>G. Boggia</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security.  It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.</p></abstract>
        <draft>draft-irtf-icnrg-evaluation-methodology-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7945</errata-url>
        <doi>10.17487/RFC7945</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7946</doc-id>
        <title>The GeoJSON Format</title>
        <author>
            <name>H. Butler</name>
        </author>
        <author>
            <name>M. Daly</name>
        </author>
        <author>
            <name>A. Doyle</name>
        </author>
        <author>
            <name>S. Gillies</name>
        </author>
        <author>
            <name>S. Hagen</name>
        </author>
        <author>
            <name>T. Schaub</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>Geospatial</kw>
            <kw>JavaScript Object Notation</kw>
        </keywords>
        <abstract><p>GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON).  It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents.  GeoJSON uses a geographic coordinate reference system, World Geodetic System 1984, and units of decimal degrees.</p></abstract>
        <draft>draft-ietf-geojson-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>geojson</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7946</errata-url>
        <doi>10.17487/RFC7946</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7947</doc-id>
        <title>Internet Exchange BGP Route Server</title>
        <author>
            <name>E. Jasinska</name>
        </author>
        <author>
            <name>N. Hilliard</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>N. Bakker</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IDR</kw>
        </keywords>
        <abstract><p>This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs).  Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server.  Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.</p></abstract>
        <draft>draft-ietf-idr-ix-bgp-route-server-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7947</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7948</doc-id>
        <title>Internet Exchange BGP Route Server Operations</title>
        <author>
            <name>N. Hilliard</name>
        </author>
        <author>
            <name>E. Jasinska</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>N. Bakker</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>GROW</kw>
        </keywords>
        <abstract><p>The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP (EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants.</p><p> Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.</p><p> This document describes operational considerations for multilateral interconnections at IXPs.</p></abstract>
        <draft>draft-ietf-grow-ix-bgp-route-server-operations-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7948</errata-url>
        <doi>10.17487/RFC7948</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7949</doc-id>
        <title>OSPFv3 over IPv4 for IPv6 Transition</title>
        <author>
            <name>I. Chen</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IPv4 transport</kw>
            <kw>OSPFv3 transition</kw>
        </keywords>
        <abstract><p>This document defines a mechanism to use IPv4 to transport OSPFv3 packets.  Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain.  This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.</p></abstract>
        <draft>draft-ietf-ospf-transition-to-ospfv3-12</draft>
        <updates>
            <doc-id>RFC5838</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC7949</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7950</doc-id>
        <title>The YANG 1.1 Data Modeling Language</title>
        <author>
            <name>M. Bjorklund</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>217</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>XML</kw>
            <kw>data modeling</kw>
        </keywords>
        <abstract><p>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</p></abstract>
        <draft>draft-ietf-netmod-rfc6020bis-14</draft>
        <updated-by>
            <doc-id>RFC8342</doc-id>
            <doc-id>RFC8526</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7950</errata-url>
        <doi>10.17487/RFC7950</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7951</doc-id>
        <title>JSON Encoding of Data Modeled with YANG</title>
        <author>
            <name>L. Lhotka</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>I-JSON</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</p></abstract>
        <draft>draft-ietf-netmod-yang-json-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7951</errata-url>
        <doi>10.17487/RFC7951</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7952</doc-id>
        <title>Defining and Using Metadata with YANG</title>
        <author>
            <name>L. Lhotka</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>metadata annotations</kw>
            <kw>YANG extension</kw>
        </keywords>
        <abstract><p>This document defines a YANG extension that allows for defining metadata annotations in YANG modules.  The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.</p></abstract>
        <draft>draft-ietf-netmod-yang-metadata-07</draft>
        <updates>
            <doc-id>RFC6110</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC7952</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7953</doc-id>
        <title>Calendar Availability</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>M. Douglass</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>availability</kw>
            <kw>calendaring</kw>
            <kw>free-busy</kw>
            <kw>iCalendar</kw>
            <kw>CalDAV</kw>
        </keywords>
        <abstract><p>This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.</p><p> This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.</p></abstract>
        <draft>draft-ietf-calext-availability-04</draft>
        <updates>
            <doc-id>RFC4791</doc-id>
            <doc-id>RFC5545</doc-id>
            <doc-id>RFC6638</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7953</errata-url>
        <doi>10.17487/RFC7953</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7954</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block</title>
        <author>
            <name>L. Iannone</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP).  The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.</p></abstract>
        <draft>draft-ietf-lisp-eid-block-13</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC7954</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7955</doc-id>
        <title>Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block</title>
        <author>
            <name>L. Iannone</name>
        </author>
        <author>
            <name>R. Jorgensen</name>
        </author>
        <author>
            <name>D. Conrad</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block.  The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.</p></abstract>
        <draft>draft-ietf-lisp-eid-block-mgmnt-07</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC7955</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7956</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway</title>
        <author>
            <name>W. Hao</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>A. Qu</name>
        </author>
        <author>
            <name>M. Durrani</name>
        </author>
        <author>
            <name>P. Sivamurugan</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>tenant</kw>
            <kw> data center</kw>
        </keywords>
        <abstract><p>The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues:</p><p> 1. Sub-optimum forwarding paths for inter-subnet traffic.</p><p> 2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.</p><p> 3. A traffic bottleneck at the gateway.</p><p> This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.</p></abstract>
        <draft>draft-ietf-trill-irb-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7956</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7957</doc-id>
        <title>DISPATCH-Style Working Groups and the SIP Change Process</title>
        <author>
            <name>B. Campbell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>dispatch</kw>
            <kw>RAI</kw>
            <kw>ART</kw>
            <kw>sip-change</kw>
        </keywords>
        <abstract><p>RFC 5727 defined several processes for the former Real-time Applications and Infrastructure (RAI) area.  These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups.  This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes.  It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups.</p></abstract>
        <draft>draft-campbell-art-rfc5727-update-03</draft>
        <updates>
            <doc-id>RFC5727</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0067</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7957</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7958</doc-id>
        <title>DNSSEC Trust Anchor Publication for the Root Zone</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>J. Schlyter</name>
        </author>
        <author>
            <name>G. Bailey</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>ICANN</kw>
            <kw>IANA</kw>
            <kw>KSK</kw>
        </keywords>
        <abstract><p>The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).</p><p> In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.</p></abstract>
        <draft>draft-jabley-dnssec-trust-anchor-16</draft>
        <obsoleted-by>
            <doc-id>RFC9718</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7958</errata-url>
        <doi>10.17487/RFC7958</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7959</doc-id>
        <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>Z. Shelby</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>Constrained Application Protocol</kw>
            <kw>REST</kw>
            <kw>Internet of Things</kw>
            <kw>IoT</kw>
            <kw>Smart Object</kw>
            <kw>Embedded Internet</kw>
            <kw>Constrained Node</kw>
        </keywords>
        <abstract><p>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</p><p> Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</p><p> A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.</p></abstract>
        <draft>draft-ietf-core-block-21</draft>
        <updates>
            <doc-id>RFC7252</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8323</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7959</errata-url>
        <doi>10.17487/RFC7959</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7960</doc-id>
        <title>Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows</title>
        <author>
            <name>F. Martin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Lear</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Draegen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Zwicky</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Andersen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>DMARC</kw>
            <kw>SMTP</kw>
            <kw>DKIM</kw>
            <kw>SPF</kw>
        </keywords>
        <abstract><p>Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting.  However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.  Collectively, these email flows are referred to as "indirect email flows".  This document describes these interoperability issues and presents possible methods for addressing them.</p></abstract>
        <draft>draft-ietf-dmarc-interoperability-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dmarc</wg_acronym>
        <doi>10.17487/RFC7960</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7961</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>L. Yizhou</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>reachability</kw>
            <kw>AFN</kw>
            <kw>template</kw>
        </keywords>
        <abstract><p>This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses.  Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable.  For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch.  Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses.</p></abstract>
        <draft>draft-ietf-trill-ia-appsubtlv-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7961</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7962</doc-id>
        <title>Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures</title>
        <author>
            <name>J. Saldana</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Arcia-Moret</name>
        </author>
        <author>
            <name>B. Braem</name>
        </author>
        <author>
            <name>E. Pietrosemoli</name>
        </author>
        <author>
            <name>A. Sathiaseelan</name>
        </author>
        <author>
            <name>M. Zennaro</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>alternative network deployments</kw>
            <kw>community networks</kw>
            <kw>user-centric networks</kw>
            <kw>Wireless Internet Service Providers</kw>
            <kw>mainstream network</kw>
            <kw>gaia</kw>
            <kw>global access to the Internet for all</kw>
        </keywords>
        <abstract><p>This document presents a taxonomy of a set of "Alternative Network Deployments" that emerged in the last decade with the aim of bringing Internet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives. They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.</p><p> The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.</p><p> The classification considers models such as Community Networks, Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.</p></abstract>
        <draft>draft-irtf-gaia-alternative-network-deployments-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC7962</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7963</doc-id>
        <title>RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs)</title>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>A. Bonfanti</name>
        </author>
        <author>
            <name>M. Hartley</name>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>GMPLS</kw>
        </keywords>
        <abstract><p>RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features.  However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2).  This document defines new Signal Types for these additional containers.</p></abstract>
        <draft>draft-ietf-ccamp-additional-signal-type-g709v3-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC7963</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7964</doc-id>
        <title>Solutions for BGP Persistent Route Oscillation</title>
        <author>
            <name>D. Walton</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>BGP churn oscillation</kw>
        </keywords>
        <abstract><p>Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies.  This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.</p></abstract>
        <draft>draft-ietf-idr-route-oscillation-stop-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC7964</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7965</doc-id>
        <title>LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels</title>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>W. Cao</name>
        </author>
        <author>
            <name>A. Takacs</name>
        </author>
        <author>
            <name>P. Pan</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes.  This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels.  The extension applies to both single-segment and multi-segment PWs.</p></abstract>
        <draft>draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC7965</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7966</doc-id>
        <title>Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>J. Korhonen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>K. Pillay</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>End-to-End Security</kw>
        </keywords>
        <abstract><p>This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).</p></abstract>
        <draft>draft-ietf-dime-e2e-sec-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC7966</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7967</doc-id>
        <title>Constrained Application Protocol (CoAP) Option for No Server Response</title>
        <author>
            <name>A. Bhattacharyya</name>
        </author>
        <author>
            <name>S. Bandyopadhyay</name>
        </author>
        <author>
            <name>A. Pal</name>
        </author>
        <author>
            <name>T. Bose</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>No-Response</kw>
        </keywords>
        <abstract><p>There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.</p><p> This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.</p></abstract>
        <draft>draft-tcs-coap-no-response-option-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7967</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7968</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data</title>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>W. Hao</name>
        </author>
        <author>
            <name>H. Chen</name>
        </author>
        <author>
            <name>S. Chatterjee</name>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>VLAN</kw>
            <kw>fine-grained label</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.</p><p> This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.</p></abstract>
        <draft>draft-ietf-trill-tree-selection-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7968</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7969</doc-id>
        <title>Customizing DHCP Configuration on the Basis of Network Topology</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>dhcpv4</kw>
            <kw>dhcpv6</kw>
            <kw>relay-agents (relay agents)</kw>
            <kw>multiple subnets</kw>
            <kw>subnets</kw>
            <kw>links</kw>
            <kw>prefixes</kw>
        </keywords>
        <abstract><p>DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications.  One aspect of this functionality is support for context-specific configuration information.  This memo describes some such features and explains their operation.</p></abstract>
        <draft>draft-ietf-dhc-topo-conf-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC7969</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7970</doc-id>
        <title>The Incident Object Description Exchange Format Version 2</title>
        <author>
            <name>R. Danyliw</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>172</page-count>
        <keywords>
            <kw>incident data format</kw>
            <kw>incident report</kw>
            <kw>cyber threat indicators</kw>
            <kw>computer security incident</kw>
            <kw>computer security incident response team</kw>
            <kw>CSIRT</kw>
            <kw>CERT</kw>
            <kw>security data sharing</kw>
            <kw>Computer Network Defense Service Provider</kw>
            <kw>CNDSP</kw>
            <kw>information sharing</kw>
            <kw>automated information sharing</kw>
            <kw>cyber indicators</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning.  This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema.  This new information and data model obsoletes RFCs 5070 and 6685.</p></abstract>
        <draft>draft-ietf-mile-rfc5070-bis-26</draft>
        <obsoletes>
            <doc-id>RFC5070</doc-id>
            <doc-id>RFC6685</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7970</errata-url>
        <doi>10.17487/RFC7970</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7971</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Deployment Considerations</title>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>S. Kiesel</name>
        </author>
        <author>
            <name>M. Scharf</name>
        </author>
        <author>
            <name>H. Seidel</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <abstract><p>Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts.  This includes, but is not limited to, peer-to-peer file sharing applications.  The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.  This memo discusses deployment-related issues of ALTO.  It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples.  The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.</p></abstract>
        <draft>draft-ietf-alto-deployments-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC7971</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7972</doc-id>
        <title>Entertainment Identifier Registry (EIDR) URN Namespace Definition</title>
        <author>
            <name>P. Lemieux</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>EIDR</kw>
            <kw>Entertainment Identifier Registry</kw>
            <kw>and URN</kw>
        </keywords>
        <abstract><p>Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.</p><p> This document obsoletes RFC 7302.</p></abstract>
        <draft>draft-pal-eidr-urn-2016-03</draft>
        <obsoletes>
            <doc-id>RFC7302</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7972</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7973</doc-id>
        <title>Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation</title>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>P. Duffy</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>6lowpan</kw>
            <kw>header compression</kw>
            <kw>ethertype</kw>
        </keywords>
        <abstract><p>When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram.  The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.</p></abstract>
        <draft>draft-ietf-6lo-ethertype-request-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC7973</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7974</doc-id>
        <title>An Experimental TCP Option for Host Identification</title>
        <author>
            <name>B. Williams</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Policy enforcement</kw>
            <kw>Address sharing</kw>
            <kw>NAT</kw>
            <kw>Host reveal</kw>
            <kw>Host-ID</kw>
        </keywords>
        <abstract><p>Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies.  Potential solutions for revealing a host identifier in shared address deployments have also been discussed.  This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.</p></abstract>
        <draft>draft-williams-exp-tcp-host-id-opt-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7974</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7975</doc-id>
        <title>Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection</title>
        <author>
            <name>B. Niven-Jenkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. van Brandenburg</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request.  This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.</p></abstract>
        <draft>draft-ietf-cdni-redirection-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC7975</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7976</doc-id>
        <title>Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>N. Biondic</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>P-</kw>
            <kw>3GPP</kw>
            <kw>IMS</kw>
        </keywords>
        <abstract><p>The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.</p><p> This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.</p></abstract>
        <draft>draft-holmberg-dispatch-rfc7315-updates-09</draft>
        <updates>
            <doc-id>RFC7315</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7976</errata-url>
        <doi>10.17487/RFC7976</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7977</doc-id>
        <title>The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)</title>
        <author>
            <name>P. Dunkley</name>
        </author>
        <author>
            <name>G. Llewellyn</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>MSRP</kw>
            <kw>WebSocket</kw>
        </keywords>
        <abstract><p>The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser).  This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios.  This document normatively updates RFCs 4975 and 4976.</p></abstract>
        <draft>draft-pd-dispatch-msrp-websocket-15</draft>
        <updates>
            <doc-id>RFC4975</doc-id>
            <doc-id>RFC4976</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC7977</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7978</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Umair</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>tunnel</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract><p>The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link.  This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages.  This document updates RFC 7178.</p></abstract>
        <draft>draft-ietf-trill-channel-tunnel-11</draft>
        <updates>
            <doc-id>RFC7178</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC7978</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7979</doc-id>
        <title>Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries</title>
        <author>
            <name>E. Lear</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Housley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>The U.S.  National Telecommunications and Information Administration (NTIA) solicited a request from the Internet Corporation for Assigned Names and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions.  After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group.  That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters.  This document contains the IETF response to that solicitation for protocol parameters.  It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities.  A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.</p></abstract>
        <draft>draft-ietf-ianaplan-icg-response-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>ianaplan</wg_acronym>
        <doi>10.17487/RFC7979</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7980</doc-id>
        <title>A Framework for Defining Network Complexity</title>
        <author>
            <name>M. Behringer</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Complicated</kw>
            <kw>Fragile</kw>
            <kw>Self-organization</kw>
            <kw>Trade-off</kw>
            <kw>Technical Debt</kw>
            <kw>Dependency</kw>
        </keywords>
        <abstract><p>Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.</p><p> This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.</p></abstract>
        <draft>draft-behringer-ncrg-complexity-framework-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC7980</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7981</doc-id>
        <title>IS-IS Extensions for Advertising Router Information</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.  This document obsoletes RFC 4971.</p></abstract>
        <draft>draft-ietf-isis-rfc4971bis-04</draft>
        <obsoletes>
            <doc-id>RFC4971</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7981</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7982</doc-id>
        <title>Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>P. Martinsen</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.</p><p> This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.</p></abstract>
        <draft>draft-ietf-tram-stun-path-data-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <doi>10.17487/RFC7982</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7983</doc-id>
        <title>Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>STUN</kw>
            <kw>TURN</kw>
            <kw>TLS</kw>
            <kw>TURN Channel Numbers</kw>
            <kw>STUN Methods</kw>
            <kw>RFC 5764</kw>
            <kw>SRTP-DTLS</kw>
            <kw>ZRTP</kw>
        </keywords>
        <abstract><p>This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document.</p><p> This document updates RFC 5764.</p></abstract>
        <draft>draft-ietf-avtcore-rfc5764-mux-fixes-11</draft>
        <updates>
            <doc-id>RFC5764</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9443</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC7983</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7984</doc-id>
        <title>Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network</title>
        <author>
            <name>O. Johansson</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>V. Gurbani</name>
        </author>
        <author>
            <name>D. Worley</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>A record</kw>
            <kw>address family preference</kw>
            <kw>AAAA record</kw>
            <kw>DNS</kw>
            <kw>getaddrinfo</kw>
            <kw>Happy Eyeballs</kw>
            <kw>IPv6 address selection</kw>
            <kw>SIP</kw>
            <kw>SRV record</kw>
            <kw>dual-stack</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures.  As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations.  This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.</p></abstract>
        <draft>draft-ietf-sipcore-dns-dual-stack-08</draft>
        <updates>
            <doc-id>RFC3263</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC7984</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7985</doc-id>
        <title>Security Threats to Simplified Multicast Forwarding (SMF)</title>
        <author>
            <name>J. Yi</name>
        </author>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>U. Herberg</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>MANET</kw>
        </keywords>
        <abstract><p>This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.</p><p> In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).</p></abstract>
        <draft>draft-ietf-manet-smf-sec-threats-06</draft>
        <updates>
            <doc-id>RFC7186</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC7985</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7986</doc-id>
        <title>New Properties for iCalendar</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>alarms</kw>
            <kw>calendaring</kw>
            <kw>iCalendar</kw>
        </keywords>
        <abstract><p>This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.</p></abstract>
        <draft>draft-ietf-calext-extensions-05</draft>
        <updates>
            <doc-id>RFC5545</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc7986</errata-url>
        <doi>10.17487/RFC7986</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7987</doc-id>
        <title>IS-IS Minimum Remaining Lifetime</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>P. Wells</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected.  In certain scenarios, this may cause or exacerbate flooding storms.  It is also a possible denial-of-service attack vector.  This document defines a backwards-compatible solution to this problem.</p></abstract>
        <draft>draft-ietf-isis-remaining-lifetime-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC7987</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7988</doc-id>
        <title>Ingress Replication Tunnels in Multicast VPN</title>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Subramanian</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers.  These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone.  One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel".  In an IR tunnel, a parent node need not be directly connected to its child nodes.  When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so.  Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node.  While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels.  This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.</p></abstract>
        <draft>draft-ietf-bess-ir-05</draft>
        <updates>
            <doc-id>RFC6513</doc-id>
            <doc-id>RFC6514</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC7988</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7989</doc-id>
        <title>End-to-End Session Identification in IP-Based Multimedia Communication Networks</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>C. Pearce</name>
        </author>
        <author>
            <name>P. Giralt</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>troubleshooting</kw>
            <kw>Session-ID</kw>
            <kw>session identifier</kw>
            <kw>H460.27</kw>
            <kw>remote parameter</kw>
            <kw>UUID</kw>
        </keywords>
        <abstract><p>This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP).</p><p> This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.</p><p> This document obsoletes RFC 7329.</p></abstract>
        <draft>draft-ietf-insipid-session-id-27</draft>
        <obsoletes>
            <doc-id>RFC7329</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>insipid</wg_acronym>
        <doi>10.17487/RFC7989</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7990</doc-id>
        <title>RFC Format Framework</title>
        <author>
            <name>H. Flanagan</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Format</kw>
            <kw>xml2rfcv3</kw>
            <kw>v3</kw>
        </keywords>
        <abstract><p>In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document.  With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs.  This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.</p></abstract>
        <draft>draft-iab-rfc-framework-06</draft>
        <obsoleted-by>
            <doc-id>RFC9720</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7990</errata-url>
        <doi>10.17487/RFC7990</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7991</doc-id>
        <title>The "xml2rfc" Version 3 Vocabulary</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>151</page-count>
        <keywords>
            <kw>v3</kw>
            <kw>xml2rfcv3</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.  It is heavily derived from the version 2 vocabulary that is also under discussion.  This document obsoletes the v2 grammar described in RFC 7749.</p></abstract>
        <draft>draft-iab-xml2rfc-04</draft>
        <obsoletes>
            <doc-id>RFC7749</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7991</errata-url>
        <doi>10.17487/RFC7991</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7992</doc-id>
        <title>HTML Format for RFCs</title>
        <author>
            <name>J. Hildebrand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>html</kw>
            <kw>css</kw>
            <kw>v3</kw>
            <kw>xml2rfcv3</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats.  This document defines the HTML format that will be rendered for an RFC or Internet-Draft.</p></abstract>
        <draft>draft-iab-html-rfc-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7992</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7993</doc-id>
        <title>Cascading Style Sheets (CSS) Requirements for RFCs</title>
        <author>
            <name>H. Flanagan</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>v3</kw>
            <kw>xml2rfcv3</kw>
            <kw>format</kw>
            <kw>html</kw>
        </keywords>
        <abstract><p>The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series.  The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model.  This document describes the requirements for the default CSS used by the RFC Editor.  The class names are based on the classes defined in "HTML for RFCs" (RFC 7992).</p></abstract>
        <draft>draft-iab-rfc-css-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7993</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7994</doc-id>
        <title>Requirements for Plain-Text RFCs</title>
        <author>
            <name>H. Flanagan</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RFC</kw>
            <kw>ASCII</kw>
            <kw>format</kw>
            <kw>plain-text</kw>
            <kw>plain text</kw>
            <kw>xml2rfcv3</kw>
            <kw>v3</kw>
        </keywords>
        <abstract><p>In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML.  The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development".  Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML.  This document outlines the rendering requirements for the plain-text RFC publication format.  These requirements do not apply to plain-text RFCs published before the format transition.</p></abstract>
        <draft>draft-iab-rfc-plaintext-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7994</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7995</doc-id>
        <title>PDF Format for RFCs</title>
        <author>
            <name>T. Hansen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>M. Hardy</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Requests for Comment</kw>
            <kw>xml2rfcv3</kw>
            <kw>v3</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949.  It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.</p></abstract>
        <draft>draft-iab-rfc-use-of-pdf-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC7995</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7996</doc-id>
        <title>SVG Drawings for RFCs: SVG 1.2 RFC</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>RFC</kw>
            <kw>v3</kw>
            <kw>xml2rfcv3</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.</p></abstract>
        <draft>draft-iab-svg-rfc-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7996</errata-url>
        <doi>10.17487/RFC7996</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7997</doc-id>
        <title>The Use of Non-ASCII Characters in RFCs</title>
        <author>
            <name>H. Flanagan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>PDF</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>RFC Series</kw>
            <kw>UTF-8</kw>
            <kw>ASCII</kw>
            <kw>format</kw>
            <kw>non-ASCII</kw>
            <kw>v3</kw>
            <kw>xml2rfcv3</kw>
        </keywords>
        <abstract><p>In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.</p><p> This document updates RFC 7322. Please view this document in PDF form to see the full text.</p></abstract>
        <draft>draft-iab-rfc-nonascii-02</draft>
        <updates>
            <doc-id>RFC7322</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7997</errata-url>
        <doi>10.17487/RFC7997</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7998</doc-id>
        <title>"xml2rfc" Version 3 Preparation Tool Description</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Hildebrand</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>xml2rfcv3</kw>
            <kw>v3</kw>
            <kw>format</kw>
        </keywords>
        <abstract><p>This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.</p></abstract>
        <draft>draft-iab-rfcv3-preptool-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc7998</errata-url>
        <doi>10.17487/RFC7998</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC7999</doc-id>
        <title>BLACKHOLE Community</title>
        <author>
            <name>T. King</name>
        </author>
        <author>
            <name>C. Dietzel</name>
        </author>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>G. Doering</name>
        </author>
        <author>
            <name>G. Hankins</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>well-known</kw>
            <kw>well known</kw>
            <kw>RTBH</kw>
            <kw>Remotely Triggered Blackholing</kw>
        </keywords>
        <abstract><p>This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks.  This well-known advisory transitive BGP community named "BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.</p></abstract>
        <draft>draft-ietf-grow-blackholing-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC7999</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8000</doc-id>
        <title>Requirements for NFSv4 Multi-Domain Namespace Deployment</title>
        <author>
            <name>A. Adamson</name>
        </author>
        <author>
            <name>N. Williams</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>multi-domain</kw>
            <kw>multi-domain-capable file system</kw>
            <kw>Federated File System</kw>
            <kw>FedFS</kw>
        </keywords>
        <abstract><p>This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains.  To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication.  In most instances, the server must also support identity-mapping services.</p></abstract>
        <draft>draft-ietf-nfsv4-multi-domain-fs-reqs-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8000</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8001</doc-id>
        <title>RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information</title>
        <author>
            <name>F. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Margaria</name>
        </author>
        <author>
            <name>M. Hartley</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).</p></abstract>
        <draft>draft-ietf-teas-rsvp-te-srlg-collect-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8001</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8002</doc-id>
        <title>Host Identity Protocol Certificates</title>
        <author>
            <name>T. Heer</name>
        </author>
        <author>
            <name>S. Varjonen</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Hip Certificate Extension</kw>
        </keywords>
        <abstract><p>The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).</p><p> The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.</p><p> This document updates RFC 7401 and obsoletes RFC 6253.</p></abstract>
        <draft>draft-ietf-hip-rfc6253-bis-09</draft>
        <obsoletes>
            <doc-id>RFC6253</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC7401</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC8002</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8003</doc-id>
        <title>Host Identity Protocol (HIP) Registration Extension</title>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>Host Identity Protocol</kw>
            <kw>Host Identity Payload</kw>
            <kw>Registration</kw>
            <kw>register</kw>
        </keywords>
        <abstract><p>This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.  This document obsoletes RFC 5203.</p></abstract>
        <draft>draft-ietf-hip-rfc5203-bis-11</draft>
        <obsoletes>
            <doc-id>RFC5203</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC8003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8004</doc-id>
        <title>Host Identity Protocol (HIP) Rendezvous Extension</title>
        <author>
            <name>J. Laganier</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>Host Identity Protocol</kw>
            <kw>Host Identity Payload</kw>
            <kw>Rendezvous</kw>
            <kw>HIP nodes</kw>
            <kw>HIP rendezvous server</kw>
        </keywords>
        <abstract><p>This document defines a rendezvous extension for the Host Identity Protocol (HIP).  The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers.  Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile.  This document obsoletes RFC 5204.</p></abstract>
        <draft>draft-ietf-hip-rfc5204-bis-08</draft>
        <obsoletes>
            <doc-id>RFC5204</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC8004</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8005</doc-id>
        <title>Host Identity Protocol (HIP) Domain Name System (DNS) Extension</title>
        <author>
            <name>J. Laganier</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>Host Identity Protocol</kw>
            <kw>Host Identity Payload</kw>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
        </keywords>
        <abstract><p>This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP).  This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs).  This document obsoletes RFC 5205.</p></abstract>
        <draft>draft-ietf-hip-rfc5205-bis-10</draft>
        <obsoletes>
            <doc-id>RFC5205</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC8005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8006</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Metadata</title>
        <author>
            <name>B. Niven-Jenkins</name>
        </author>
        <author>
            <name>R. Murray</name>
        </author>
        <author>
            <name>M. Caulfield</name>
        </author>
        <author>
            <name>K. Ma</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>CDN</kw>
            <kw>cascaded CDN</kw>
            <kw>cascading CDNs</kw>
            <kw>content acquisition</kw>
            <kw>content delegation</kw>
            <kw>request delegation</kw>
            <kw>acquisition protocol</kw>
            <kw>delivery restriction</kw>
            <kw>delivery policy</kw>
            <kw>policy enforcement</kw>
            <kw>delivery protocol</kw>
            <kw>content expiration</kw>
            <kw>geo-fencing</kw>
            <kw>geofencing</kw>
            <kw>geo fencing</kw>
            <kw>geo-blocking</kw>
            <kw> geoblocking</kw>
            <kw>geo blocking</kw>
            <kw>footprint</kw>
            <kw>cache control</kw>
        </keywords>
        <abstract><p>The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery.  The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN.  This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.</p></abstract>
        <draft>draft-ietf-cdni-metadata-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8006</errata-url>
        <doi>10.17487/RFC8006</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8007</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Control Interface / Triggers</title>
        <author>
            <name>R. Murray</name>
        </author>
        <author>
            <name>B. Niven-Jenkins</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>CDN</kw>
            <kw>pre-position</kw>
            <kw>invalidate</kw>
            <kw>purge</kw>
        </keywords>
        <abstract><p>This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf.  The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content.  The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN.</p></abstract>
        <draft>draft-ietf-cdni-control-triggers-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8007</errata-url>
        <doi>10.17487/RFC8007</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8008</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics</title>
        <author>
            <name>J. Seedorf</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>R. van Brandenburg</name>
        </author>
        <author>
            <name>K. Ma</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>CDNI</kw>
            <kw>CDN Interconnect</kw>
            <kw>Request Routing</kw>
        </keywords>
        <abstract><p>This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint &amp; Capabilities Advertisement interface (FCI)" offers within CDNI.  The document also provides guidelines for the CDNI FCI protocol.  It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.</p></abstract>
        <draft>draft-ietf-cdni-footprint-capabilities-semantics-20</draft>
        <updated-by>
            <doc-id>RFC9388</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC8008</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8009</doc-id>
        <title>AES Encryption with HMAC-SHA2 for Kerberos 5</title>
        <author>
            <name>M. Jenkins</name>
        </author>
        <author>
            <name>M. Peck</name>
        </author>
        <author>
            <name>K. Burgin</name>
        </author>
        <date>
            <month>October</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document specifies two encryption types and two corresponding checksum types for Kerberos 5.  The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity.</p></abstract>
        <draft>draft-ietf-kitten-aes-cts-hmac-sha2-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC8009</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8010</doc-id>
        <title>Internet Printing Protocol/1.1: Encoding and Transport</title>
        <author>
            <name>M. Sweet</name>
        </author>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>IPP</kw>
            <kw>Printer</kw>
            <kw>PWG</kw>
            <kw>Printer Working Group</kw>
        </keywords>
        <abstract><p>The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies.  This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ipp".  It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS.  The IPP data model and operation semantics are described in "Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).</p></abstract>
        <draft>draft-sweet-rfc2910bis-10</draft>
        <obsoletes>
            <doc-id>RFC2910</doc-id>
            <doc-id>RFC3382</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0092</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8010</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8011</doc-id>
        <title>Internet Printing Protocol/1.1: Model and Semantics</title>
        <author>
            <name>M. Sweet</name>
        </author>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>221</page-count>
        <keywords>
            <kw>IPP</kw>
            <kw>Printer</kw>
            <kw>PWG</kw>
            <kw>Printer Working Group</kw>
        </keywords>
        <abstract><p>The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents.</p><p> IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of Print Jobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers.</p><p> Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in "Internet Printing Protocol/1.1: Encoding and Transport" (RFC 8010).</p><p> This document obsoletes RFCs 2911, 3381, and 3382.</p></abstract>
        <draft>draft-sweet-rfc2911bis-11</draft>
        <obsoletes>
            <doc-id>RFC2911</doc-id>
            <doc-id>RFC3381</doc-id>
            <doc-id>RFC3382</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0092</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8011</errata-url>
        <doi>10.17487/RFC8011</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8012</doc-id>
        <title>Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)</title>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LSP Ping</kw>
            <kw>and Entropy</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC 4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where Label Switching Routers (LSRs) apply different load-balancing techniques. One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g., IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.</p><p> This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790.</p></abstract>
        <draft>draft-ietf-mpls-entropy-lsp-ping-05</draft>
        <updates>
            <doc-id>RFC6790</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8012</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8013</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)</title>
        <author>
            <name>D. Joachimpillai</name>
        </author>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ForCES</kw>
            <kw>Inter-FE</kw>
        </keywords>
        <abstract><p>This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class.  The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification.  The document focuses on Ethernet transport.</p></abstract>
        <draft>draft-ietf-forces-interfelfb-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8013</errata-url>
        <doi>10.17487/RFC8013</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8014</doc-id>
        <title>An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>J. Hudson</name>
        </author>
        <author>
            <name>L. Kreeger</name>
        </author>
        <author>
            <name>M. Lasserre</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks.  The architecture is given at a high level, showing the major components of an overall system.  An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions.  It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components.  That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.</p></abstract>
        <draft>draft-ietf-nvo3-arch-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC8014</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8015</doc-id>
        <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics</title>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>A. Clark</name>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>XRBLOCK</kw>
        </keywords>
        <abstract><p>This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.</p></abstract>
        <draft>draft-ietf-xrblock-independent-burst-gap-discard-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC8015</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8016</doc-id>
        <title>Mobility with Traversal Using Relays around NAT (TURN)</title>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>P. Patil</name>
        </author>
        <author>
            <name>P. Martinsen</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IP Address Mobility</kw>
            <kw>VoIP</kw>
            <kw>ICE</kw>
            <kw>STUN</kw>
            <kw>RTP</kw>
            <kw>TUNNEL</kw>
        </keywords>
        <abstract><p>It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.</p><p> This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.</p></abstract>
        <draft>draft-ietf-tram-turn-mobility-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8016</errata-url>
        <doi>10.17487/RFC8016</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8017</doc-id>
        <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
        <author>
            <name>K. Moriarty</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <author>
            <name>J. Jonsson</name>
        </author>
        <author>
            <name>A. Rusch</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>78</page-count>
        <keywords>
            <kw>RSA public-key cryptosystem</kw>
            <kw>RSA signature scheme</kw>
            <kw>RSA public key</kw>
            <kw>RSA private key</kw>
            <kw>PKCS #1 v1.5</kw>
            <kw>RSA-OAEP</kw>
            <kw>RSA-PSS</kw>
            <kw>Optimal Asymmetric Encryption Padding</kw>
            <kw>Probabilistic Signature Scheme</kw>
        </keywords>
        <abstract><p>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</p><p> This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</p><p> This document also obsoletes RFC 3447.</p></abstract>
        <draft>draft-moriarty-pkcs1-03</draft>
        <obsoletes>
            <doc-id>RFC3447</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8017</errata-url>
        <doi>10.17487/RFC8017</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8018</doc-id>
        <title>PKCS #5: Password-Based Cryptography Specification Version 2.1</title>
        <author>
            <name>K. Moriarty</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <author>
            <name>A. Rusch</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>password-based encryption</kw>
            <kw>password-based key derivation</kw>
            <kw>salt</kw>
        </keywords>
        <abstract><p>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.</p><p> This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</p><p> This document also obsoletes RFC 2898.</p></abstract>
        <draft>draft-moriarty-pkcs5-v2dot1-04</draft>
        <obsoletes>
            <doc-id>RFC2898</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9579</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8018</errata-url>
        <doi>10.17487/RFC8018</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8019</doc-id>
        <title>Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>puzzle</kw>
            <kw>dos</kw>
            <kw>ddos</kw>
            <kw>bitcoin</kw>
        </keywords>
        <abstract><p>This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks.  Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.</p></abstract>
        <draft>draft-ietf-ipsecme-ddos-protection-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8019</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8020</doc-id>
        <title>NXDOMAIN: There Really Is Nothing Underneath</title>
        <author>
            <name>S. Bortzmeyer</name>
        </author>
        <author>
            <name>S. Huque</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.</p><p> This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.</p></abstract>
        <draft>draft-ietf-dnsop-nxdomain-cut-05</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC2308</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8020</errata-url>
        <doi>10.17487/RFC8020</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8021</doc-id>
        <title>Generation of IPv6 Atomic Fragments Considered Harmful</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <author>
            <name>T. Anderson</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>attack</kw>
            <kw>DoS</kw>
            <kw>Extension Headers</kw>
        </keywords>
        <abstract><p>This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments.  It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460).</p></abstract>
        <draft>draft-ietf-6man-deprecate-atomfrag-generation-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8021</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8022</doc-id>
        <title>A YANG Data Model for Routing Management</title>
        <author>
            <name>L. Lhotka</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>configuration</kw>
            <kw>IPv6 router advertisements</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document contains a specification of three YANG modules and one submodule.  Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem.  It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions.  The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</p></abstract>
        <draft>draft-ietf-netmod-routing-cfg-25</draft>
        <obsoleted-by>
            <doc-id>RFC8349</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8022</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8023</doc-id>
        <title>Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions</title>
        <author>
            <name>M. Thomas</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, United Kingdom, from March 8 to 10, 2014.  The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions.  This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.</p></abstract>
        <draft>draft-thomas-namecollisions-workshop-report-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8024</doc-id>
        <title>Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS</title>
        <author>
            <name>Y. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Luo</name>
        </author>
        <author>
            <name>E. Mallette</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Shen</name>
        </author>
        <author>
            <name>W. Cheng</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PON Protection</kw>
        </keywords>
        <abstract><p>Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes.  Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge.  Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services.  This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it.</p></abstract>
        <draft>draft-ietf-pals-mc-pon-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8024</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8025</doc-id>
        <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Cragie</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>LNN</kw>
            <kw>IOT</kw>
        </keywords>
        <abstract><p>This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.</p></abstract>
        <draft>draft-ietf-6lo-paging-dispatch-05</draft>
        <updates>
            <doc-id>RFC4944</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC8025</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8026</doc-id>
        <title>Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Provisioning</kw>
            <kw>Softwire</kw>
            <kw>IPv4 over IPv6</kw>
            <kw>IPv4 service continuity</kw>
            <kw>IPv4 address depletion</kw>
            <kw>MAP</kw>
            <kw>MAP-T</kw>
            <kw>MAP-E</kw>
            <kw>DS-Lite</kw>
            <kw>Lightweight 4 over 6</kw>
        </keywords>
        <abstract><p>In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity.  A number of differing functional approaches have been developed for this, each having their own specific characteristics.  As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.</p></abstract>
        <draft>draft-ietf-softwire-unified-cpe-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8026</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8027</doc-id>
        <title>DNSSEC Roadblock Avoidance</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>S. Krishnaswamy</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>Network Problems</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure.  It outlines potential detection and mitigation techniques.  The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-roadblock-avoidance-05</draft>
        <is-also>
            <doc-id>BCP0207</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8027</errata-url>
        <doi>10.17487/RFC8027</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8028</doc-id>
        <title>First-Hop Router Selection by Hosts in a Multi-Prefix Network</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from.  It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters.  Host behavior in choosing a first-hop router may interact with source address selection in a given implementation.  However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen.  Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission.  It updates RFC 4861.</p></abstract>
        <draft>draft-ietf-6man-multi-homed-host-10</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8028</errata-url>
        <doi>10.17487/RFC8028</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8029</doc-id>
        <title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Kumar</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>78</page-count>
        <keywords>
            <kw>MPLS echo request</kw>
            <kw>MPLS echo reply</kw>
        </keywords>
        <abstract><p>This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.</p><p> This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.</p></abstract>
        <draft>draft-ietf-mpls-rfc4379bis-09</draft>
        <obsoletes>
            <doc-id>RFC4379</doc-id>
            <doc-id>RFC6424</doc-id>
            <doc-id>RFC6829</doc-id>
            <doc-id>RFC7537</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1122</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8611</doc-id>
            <doc-id>RFC9041</doc-id>
            <doc-id>RFC9570</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8029</errata-url>
        <doi>10.17487/RFC8029</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8030</doc-id>
        <title>Generic Event Delivery Using HTTP Push</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>E. Damaggio</name>
        </author>
        <author>
            <name>B. Raymor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>HTTP2</kw>
            <kw>Push</kw>
            <kw>WebPush</kw>
        </keywords>
        <abstract><p>This document describes a simple protocol for the delivery of real- time events to user agents.  This scheme uses HTTP/2 server push.</p></abstract>
        <draft>draft-ietf-webpush-protocol-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>webpush</wg_acronym>
        <doi>10.17487/RFC8030</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8031</doc-id>
        <title>Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Curve25519</kw>
            <kw>Curve448</kw>
            <kw>Goldilocks</kw>
            <kw>Diffie Hellman</kw>
        </keywords>
        <abstract><p>This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).</p></abstract>
        <draft>draft-ietf-ipsecme-safecurves-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8031</errata-url>
        <doi>10.17487/RFC8031</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8032</doc-id>
        <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>I. Liusvaara</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>signature</kw>
            <kw>digital signature</kw>
            <kw>EdDSA</kw>
        </keywords>
        <abstract><p>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves.  An example implementation and test vectors are provided.</p></abstract>
        <draft>draft-irtf-cfrg-eddsa-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8032</errata-url>
        <doi>10.17487/RFC8032</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8033</doc-id>
        <title>Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem</title>
        <author>
            <name>R. Pan</name>
        </author>
        <author>
            <name>P. Natarajan</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>G. White</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>active queue management</kw>
            <kw>AQM</kw>
        </keywords>
        <abstract><p>Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.</p><p> This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value. Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.</p></abstract>
        <draft>draft-ietf-aqm-pie-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8033</errata-url>
        <doi>10.17487/RFC8033</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8034</doc-id>
        <title>Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems</title>
        <author>
            <name>G. White</name>
        </author>
        <author>
            <name>R. Pan</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>latency</kw>
            <kw>access network</kw>
            <kw>bufferbloat</kw>
        </keywords>
        <abstract><p>Cable modems based on Data-Over-Cable Service Interface Specifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide.  In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet.  As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience.  The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance.  In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements.  This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.</p></abstract>
        <draft>draft-ietf-aqm-docsis-pie-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <doi>10.17487/RFC8034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8035</doc-id>
        <title>Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>November</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>RTCP</kw>
            <kw>multiplex</kw>
            <kw>rtcp-mux</kw>
            <kw>SDP</kw>
            <kw>offer</kw>
            <kw>answer</kw>
        </keywords>
        <abstract><p>This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing.  It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.</p></abstract>
        <draft>draft-ietf-avtcore-5761-update-06</draft>
        <updates>
            <doc-id>RFC5761</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8035</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8036</doc-id>
        <title>Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks</title>
        <author>
            <name>N. Cam-Winget</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Hui</name>
        </author>
        <author>
            <name>D. Popa</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>constrained environment</kw>
            <kw>smart meter</kw>
            <kw>utilities</kw>
            <kw>smartgrid</kw>
            <kw>secure smartgrid</kw>
            <kw>connected energy</kw>
        </keywords>
        <abstract><p>This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.</p></abstract>
        <draft>draft-ietf-roll-applicability-ami-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC8036</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8037</doc-id>
        <title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)</title>
        <author>
            <name>I. Liusvaara</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Ed25519</kw>
            <kw>Ed448</kw>
            <kw>X25519</kw>
            <kw>X448</kw>
        </keywords>
        <abstract><p>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).</p></abstract>
        <draft>draft-ietf-jose-cfrg-curves-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>jose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8037</errata-url>
        <doi>10.17487/RFC8037</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8038</doc-id>
        <title>Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol</title>
        <author>
            <name>P. Aitken</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>S. B S</name>
        </author>
        <author>
            <name>C. McDowall</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>MIB</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract><p>This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.</p><p> Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.</p></abstract>
        <draft>draft-ietf-ipfix-mib-variable-export-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8038</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8039</doc-id>
        <title>Multipath Time Synchronization</title>
        <author>
            <name>A. Shpiner</name>
        </author>
        <author>
            <name>R. Tse</name>
        </author>
        <author>
            <name>C. Schelp</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>PTP</kw>
            <kw>IEEE 1588</kw>
            <kw>multiple paths</kw>
        </keywords>
        <abstract><p>Clock synchronization protocols are very widely used in IP-based networks.  The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP).  As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy.  This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols.  The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance.  The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.</p></abstract>
        <draft>draft-ietf-tictoc-multi-path-synchronization-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tictoc</wg_acronym>
        <doi>10.17487/RFC8039</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8040</doc-id>
        <title>RESTCONF Protocol</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>137</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>NETCONF</kw>
            <kw>REST</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</p></abstract>
        <draft>draft-ietf-netconf-restconf-18</draft>
        <updated-by>
            <doc-id>RFC8527</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8040</errata-url>
        <doi>10.17487/RFC8040</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8041</doc-id>
        <title>Use Cases and Operational Experience with Multipath TCP</title>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <author>
            <name>C. Paasch</name>
        </author>
        <author>
            <name>G. Detal</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>MPTCP</kw>
            <kw>Middlebox</kw>
            <kw>Congestion Control</kw>
            <kw>Path Manager</kw>
            <kw>Scheduler</kw>
            <kw>Proxy</kw>
            <kw>Load-Balancer</kw>
            <kw>Datacenter</kw>
            <kw>Cellular/WiFi Offload</kw>
            <kw>Hybrid Access Networks</kw>
        </keywords>
        <abstract><p>This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks.  It lists several prominent use cases where Multipath TCP has been considered and is being used.  It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.</p></abstract>
        <draft>draft-ietf-mptcp-experience-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <doi>10.17487/RFC8041</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8042</doc-id>
        <title>OSPF Two-Part Metric</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>Broadcast</kw>
            <kw>Interface</kw>
            <kw>SPF metrics</kw>
            <kw>Radio Networks</kw>
        </keywords>
        <abstract><p>This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router.  For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts.  This document updates RFC 2328.</p></abstract>
        <draft>draft-ietf-ospf-two-part-metric-10</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC8042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8043</doc-id>
        <title>Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space</title>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Neighbor Discovery</kw>
            <kw>Duplicate Address Detection</kw>
            <kw>ND Relay Agent</kw>
        </keywords>
        <abstract><p>This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.</p><p> The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.</p></abstract>
        <draft>draft-sarikaya-6man-sadr-overview-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8043</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8044</doc-id>
        <title>Data Types in RADIUS</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>RADIUS specifications have used data types for two decades without defining them as managed entities.  During this time, RADIUS implementations have named the data types and have used them in attribute definitions.  This document updates the specifications to better follow established practice.  We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865.  We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute.  Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice.  This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.</p></abstract>
        <draft>draft-ietf-radext-datatypes-08</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
            <doc-id>RFC3162</doc-id>
            <doc-id>RFC4072</doc-id>
            <doc-id>RFC6158</doc-id>
            <doc-id>RFC6572</doc-id>
            <doc-id>RFC7268</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC8044</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8045</doc-id>
        <title>RADIUS Extensions for IP Port Configuration and Reporting</title>
        <author>
            <name>D. Cheng</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>address sharing</kw>
            <kw>address continuity</kw>
            <kw>CGN</kw>
            <kw>NAT</kw>
            <kw>IP assignment</kw>
            <kw>port assignment</kw>
            <kw>port control</kw>
            <kw>port accounting</kw>
            <kw>port set</kw>
            <kw>port range</kw>
            <kw>IP/Port Limit</kw>
            <kw>Provider Wi-Fi</kw>
            <kw>Port forwarding</kw>
            <kw>Internal port</kw>
            <kw>External port</kw>
            <kw>Port mapping</kw>
        </keywords>
        <abstract><p>This document defines three new RADIUS attributes.  For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts.  This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc.  This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers.</p></abstract>
        <draft>draft-ietf-radext-ip-port-radius-ext-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8045</errata-url>
        <doi>10.17487/RFC8045</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8046</doc-id>
        <title>Host Mobility with the Host Identity Protocol</title>
        <author>
            <name>T. Henderson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Vogt</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>hip</kw>
            <kw>multihoming extensions</kw>
            <kw>mobility extensions</kw>
            <kw>locator</kw>
        </keywords>
        <abstract><p>This document defines a mobility extension to the Host Identity Protocol (HIP).  Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached.  This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts.  The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047).  This document obsoletes RFC 5206.</p></abstract>
        <draft>draft-ietf-hip-rfc5206-bis-14</draft>
        <obsoletes>
            <doc-id>RFC5206</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC8046</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8047</doc-id>
        <title>Host Multihoming with the Host Identity Protocol</title>
        <author>
            <name>T. Henderson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Vogt</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>hip</kw>
            <kw>multihoming extensions</kw>
            <kw>mobility extensions</kw>
            <kw>locator</kw>
        </keywords>
        <abstract><p>This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.</p></abstract>
        <draft>draft-ietf-hip-multihoming-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC8047</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8048</doc-id>
        <title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>December</month>
            <year>2016</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Extensible Messaging and Presence Protocol</kw>
            <kw>XMPP</kw>
            <kw>Jabber</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>SIP</kw>
            <kw>SIMPLE</kw>
            <kw>presence</kw>
            <kw>availability</kw>
        </keywords>
        <abstract><p>This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).  This document obsoletes RFC 7248.</p></abstract>
        <draft>draft-ietf-stox-7248bis-14</draft>
        <obsoletes>
            <doc-id>RFC7248</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stox</wg_acronym>
        <doi>10.17487/RFC8048</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8049</doc-id>
        <title>YANG Data Model for L3VPN Service Delivery</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>L. Tomotaki</name>
        </author>
        <author>
            <name>K. Ogaki</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>157</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>l3sm</kw>
            <kw>l3vpn</kw>
            <kw>service model</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service.  This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This model is intended to be instantiated at the management system to deliver the overall service.  It is not a configuration model to be used directly on network elements.  This model provides an abstracted view of the Layer 3 IP VPN service configuration components.  It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service.  How the configuration of network elements is done is out of scope for this document.</p></abstract>
        <draft>draft-ietf-l3sm-l3vpn-service-model-19</draft>
        <obsoleted-by>
            <doc-id>RFC8299</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>l3sm</wg_acronym>
        <doi>10.17487/RFC8049</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8050</doc-id>
        <title>Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions</title>
        <author>
            <name>C. Petrie</name>
        </author>
        <author>
            <name>T. King</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions.</p></abstract>
        <draft>draft-ietf-grow-mrt-add-paths-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC8050</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8051</doc-id>
        <title>Applicability of a Stateful Path Computation Element (PCE)</title>
        <author>
            <name>X. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Minei</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Stateful PCE</kw>
            <kw>Applicability</kw>
        </keywords>
        <abstract><p>A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs).  This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases.  PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-app-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8051</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8052</doc-id>
        <title>Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services</title>
        <author>
            <name>B. Weis</name>
        </author>
        <author>
            <name>M. Seewald</name>
        </author>
        <author>
            <name>H. Falk</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>The IEC 61850 power utility automation family of standards describes methods using Ethernet and IP for distributing control and data frames within and between substations.  The IEC 61850-90-5 and IEC 62351-9 standards specify the use of the Group Domain of Interpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols.  This memo defines GDOI payloads to support those security protocols.</p></abstract>
        <draft>draft-weis-gdoi-iec62351-9-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8052</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8053</doc-id>
        <title>HTTP Authentication Extensions for Interactive Clients</title>
        <author>
            <name>Y. Oiwa</name>
        </author>
        <author>
            <name>H. Watanabe</name>
        </author>
        <author>
            <name>H. Takagi</name>
        </author>
        <author>
            <name>K. Maeda</name>
        </author>
        <author>
            <name>T. Hayashi</name>
        </author>
        <author>
            <name>Y. Ioku</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document specifies extensions for the HTTP authentication framework for interactive clients.  Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications.  This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents.  The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.</p></abstract>
        <draft>draft-ietf-httpauth-extension-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <doi>10.17487/RFC8053</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8054</doc-id>
        <title>Network News Transfer Protocol (NNTP) Extension for Compression</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <author>
            <name>J. Elie</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>NNTP</kw>
            <kw>Usenet</kw>
            <kw>NetNews</kw>
            <kw>COMPRESS</kw>
            <kw>DEFLATE</kw>
            <kw>compression</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Network News Transport Protocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server.</p></abstract>
        <draft>draft-murchison-nntp-compress-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8054</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8055</doc-id>
        <title>Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>Y. Jiang</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Via</kw>
            <kw>transit</kw>
            <kw>realm</kw>
        </keywords>
        <abstract><p>This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.</p></abstract>
        <draft>draft-holmberg-dispatch-received-realm-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8055</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8056</doc-id>
        <title>Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping</title>
        <author>
            <name>J. Gould</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP).  This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP.</p></abstract>
        <draft>draft-ietf-regext-epp-rdap-status-mapping-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8056</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8057</doc-id>
        <title>Uniform Resource Name (URN) Namespaces for Broadband Forum</title>
        <author>
            <name>B. Stark</name>
        </author>
        <author>
            <name>D. Sinicrope</name>
        </author>
        <author>
            <name>W. Lupton</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>URN</kw>
            <kw>Broadband Forum</kw>
            <kw>BBF</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifiers (NIDs) "bbf", "broadband-forum-org", and "dslforum-org" for Uniform Resource Names (URNs) used to identify resources published by Broadband Forum (BBF).  BBF specifies and manages resources that utilize these three URN identification models.  Management activities for these and other resource types are handled by BBF.</p></abstract>
        <draft>draft-bbf-bbf-urn-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8057</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8058</doc-id>
        <title>Signaling One-Click Functionality for List Email Headers</title>
        <author>
            <name>J. Levine</name>
        </author>
        <author>
            <name>T. Herkula</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>email</kw>
            <kw>mailing list</kw>
        </keywords>
        <abstract><p>This document describes a method for signaling a one-click function for the List-Unsubscribe email header field.  The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.</p></abstract>
        <draft>draft-levine-herkula-oneclick-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8058</errata-url>
        <doi>10.17487/RFC8058</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8059</doc-id>
        <title>PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments</title>
        <author>
            <name>J. Arango</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites.  These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).</p></abstract>
        <draft>draft-ietf-pim-join-attributes-for-lisp-06</draft>
        <updated-by>
            <doc-id>RFC9798</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8059</errata-url>
        <doi>10.17487/RFC8059</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8060</doc-id>
        <title>LISP Canonical Address Format (LCAF)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>J. Snijders</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Locator/ID Separation Protocol</kw>
        </keywords>
        <abstract><p>This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.</p></abstract>
        <draft>draft-ietf-lisp-lcaf-22</draft>
        <updated-by>
            <doc-id>RFC9306</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8060</errata-url>
        <doi>10.17487/RFC8060</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8061</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>lcaf</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP).  The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.</p></abstract>
        <draft>draft-ietf-lisp-crypto-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC8061</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8062</doc-id>
        <title>Anonymity Support for Kerberos</title>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>S. Hartman</name>
        </author>
        <author>
            <name>S. Emery</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm.  It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC).  This document updates RFCs 4120, 4121, and 4556.  This document obsoletes RFC 6112 and reclassifies that document as Historic.  RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation.  This specification describes a protocol that interoperates with multiple implementations.</p></abstract>
        <draft>draft-ietf-kitten-rfc6112bis-03</draft>
        <obsoletes>
            <doc-id>RFC6112</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4120</doc-id>
            <doc-id>RFC4121</doc-id>
            <doc-id>RFC4556</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC8062</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8063</doc-id>
        <title>Key Relay Mapping for the Extensible Provisioning Protocol</title>
        <author>
            <name>H.W. Ribbers</name>
        </author>
        <author>
            <name>M.W. Groeneweg</name>
        </author>
        <author>
            <name>R. Gieben</name>
        </author>
        <author>
            <name>A.L.J. Verschuren</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Extensible Provisioning Protocol</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.</p><p> This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.</p></abstract>
        <draft>draft-ietf-eppext-keyrelay-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8063</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8064</doc-id>
        <title>Recommendation on Stable IPv6 Interface Identifiers</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.  It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs.  It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121.  This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.</p></abstract>
        <draft>draft-ietf-6man-default-iids-16</draft>
        <updates>
            <doc-id>RFC2464</doc-id>
            <doc-id>RFC2467</doc-id>
            <doc-id>RFC2470</doc-id>
            <doc-id>RFC2491</doc-id>
            <doc-id>RFC2492</doc-id>
            <doc-id>RFC2497</doc-id>
            <doc-id>RFC2590</doc-id>
            <doc-id>RFC3146</doc-id>
            <doc-id>RFC3572</doc-id>
            <doc-id>RFC4291</doc-id>
            <doc-id>RFC4338</doc-id>
            <doc-id>RFC4391</doc-id>
            <doc-id>RFC5072</doc-id>
            <doc-id>RFC5121</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8064</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8065</doc-id>
        <title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.</p></abstract>
        <draft>draft-ietf-6lo-privacy-considerations-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC8065</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8066</doc-id>
        <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines</title>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>J. Woodyatt</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header.  The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944.  This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.</p></abstract>
        <draft>draft-ietf-6lo-dispatch-iana-registry-07</draft>
        <updates>
            <doc-id>RFC4944</doc-id>
            <doc-id>RFC6282</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC8066</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8067</doc-id>
        <title>Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>January</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>downref</kw>
            <kw>maturity</kw>
            <kw>last call</kw>
        </keywords>
        <abstract><p>RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice.  That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.</p></abstract>
        <draft>draft-leiba-3967upd-downref-03</draft>
        <updates>
            <doc-id>RFC3967</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0097</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8067</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8068</doc-id>
        <title>Session Initiation Protocol (SIP) Recording Call Flows</title>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>P. Ravindran</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>sipreq</kw>
        </keywords>
        <abstract><p>Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations.  In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons.  The recording of a session is typically performed by sending a copy of a media stream to a recording device.  This document lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS).</p></abstract>
        <draft>draft-ietf-siprec-callflows-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>siprec</wg_acronym>
        <doi>10.17487/RFC8068</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8069</doc-id>
        <title>URN Namespace for IEEE</title>
        <author>
            <name>A. Thomas</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document describes the Namespace Identifier (NID) 'ieee' for Uniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE).  IEEE specifies and manages resources that utilize this URN identification model.  Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority.</p></abstract>
        <draft>draft-ieee-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8069</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8070</doc-id>
        <title>Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension</title>
        <author>
            <name>M. Short</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Moore</name>
        </author>
        <author>
            <name>P. Miller</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange.</p></abstract>
        <draft>draft-ietf-kitten-pkinit-freshness-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC8070</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8071</doc-id>
        <title>NETCONF Call Home and RESTCONF Call Home</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>call-home</kw>
        </keywords>
        <abstract><p>This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively.</p></abstract>
        <draft>draft-ietf-netconf-call-home-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC8071</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8072</doc-id>
        <title>YANG Patch Media Type</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.</p></abstract>
        <draft>draft-ietf-netconf-yang-patch-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8072</errata-url>
        <doi>10.17487/RFC8072</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8073</doc-id>
        <title>Coordinating Attack Response at Internet Scale (CARIS) Workshop Report</title>
        <author>
            <name>K. Moriarty</name>
        </author>
        <author>
            <name>M. Ford</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-carisreport-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8073</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8074</doc-id>
        <title>Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario</title>
        <author>
            <name>J. Bi</name>
        </author>
        <author>
            <name>G. Yao</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>E. Levy-Abegnoli</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SAVI-DHCP</kw>
            <kw>FCFS SAVI</kw>
            <kw>SEND SAVI</kw>
        </keywords>
        <abstract><p>In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods.  This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.</p></abstract>
        <draft>draft-ietf-savi-mix-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>savi</wg_acronym>
        <doi>10.17487/RFC8074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8075</doc-id>
        <title>Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>A. Castellani</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>A. Rahman</name>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <author>
            <name>E. Dijk</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>HTTP-CoAP mapping</kw>
            <kw>HTTP-CoAP translation</kw>
            <kw>proxy implementation</kw>
        </keywords>
        <abstract><p>This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP).  This will enable an HTTP client to access resources on a CoAP server through the proxy.  This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response.  This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.</p></abstract>
        <draft>draft-ietf-core-http-mapping-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8075</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8076</doc-id>
        <title>A Usage for Shared Resources in RELOAD (ShaRe)</title>
        <author>
            <name>A. Knauf</name>
        </author>
        <author>
            <name>T. Schmidt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Hege</name>
        </author>
        <author>
            <name>M. Waehlisch</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>P2PSIP</kw>
            <kw>SIP</kw>
            <kw>Conferencing</kw>
            <kw>Voice over IP</kw>
            <kw>Peer-to-Peer</kw>
            <kw>Access Control</kw>
            <kw>Group Management</kw>
            <kw>Rendezvous</kw>
        </keywords>
        <abstract><p>This document defines a REsource LOcation And Discovery (RELOAD) Usage for managing shared write access to RELOAD Resources.  Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers.  Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list.  A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate.  This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required.</p></abstract>
        <draft>draft-ietf-p2psip-share-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>p2psip</wg_acronym>
        <doi>10.17487/RFC8076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8077</doc-id>
        <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
        <author>
            <name>L. Martini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Heron</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</p><p> This document is a rewrite of RFC 4447 for publication as an Internet Standard.</p></abstract>
        <draft>draft-ietf-pals-rfc4447bis-05</draft>
        <obsoletes>
            <doc-id>RFC4447</doc-id>
            <doc-id>RFC6723</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0084</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8077</errata-url>
        <doi>10.17487/RFC8077</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8078</doc-id>
        <title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>dnssec</kw>
            <kw>trust maintenance</kw>
        </keywords>
        <abstract><p>RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.</p><p> Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.</p><p> This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).</p><p> It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.</p></abstract>
        <draft>draft-ietf-dnsop-maintain-ds-06</draft>
        <updates>
            <doc-id>RFC7344</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9615</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8078</errata-url>
        <doi>10.17487/RFC8078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8079</doc-id>
        <title>Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)</title>
        <author>
            <name>L. Miniero</name>
        </author>
        <author>
            <name>S. Garcia Murillo</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.</p><p> This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.</p></abstract>
        <draft>draft-ietf-straw-b2bua-rtcp-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>straw</wg_acronym>
        <doi>10.17487/RFC8079</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8080</doc-id>
        <title>Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC</title>
        <author>
            <name>O. Sury</name>
        </author>
        <author>
            <name>R. Edmonds</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>EdDSA</kw>
            <kw>ed25519</kw>
            <kw>ed448</kw>
        </keywords>
        <abstract><p>This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC).  It uses EdDSA with the choice of two curves: Ed25519 and Ed448.</p></abstract>
        <draft>draft-ietf-curdle-dnskey-eddsa-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8080</errata-url>
        <doi>10.17487/RFC8080</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8081</doc-id>
        <title>The "font" Top-Level Media Type</title>
        <author>
            <name>C. Lilley</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Internet Media Types</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract><p>This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered.  This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations.</p></abstract>
        <draft>draft-ietf-justfont-toplevel-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>justfont</wg_acronym>
        <doi>10.17487/RFC8081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8082</doc-id>
        <title>Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs</title>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>B. Burman</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Layered Codec</kw>
            <kw>Full Intra Request</kw>
            <kw>FIR</kw>
            <kw>Decoder Refresh Point</kw>
        </keywords>
        <abstract><p>This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs.  In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows.  The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.</p></abstract>
        <draft>draft-ietf-avtext-avpf-ccm-layered-04</draft>
        <updates>
            <doc-id>RFC5104</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC8082</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8083</doc-id>
        <title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.</p><p> This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-circuit-breakers-18</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8083</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8084</doc-id>
        <title>Network Transport Circuit Breakers</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Congestion control</kw>
            <kw>CC</kw>
            <kw>UDP</kw>
            <kw>Tunnel</kw>
            <kw>Encapsulation</kw>
            <kw>Transport Protocol</kw>
            <kw>Congestion Control</kw>
        </keywords>
        <abstract><p>This document explains what is meant by the term "network transport Circuit Breaker".  It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.  It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.</p></abstract>
        <draft>draft-ietf-tsvwg-circuit-breaker-15</draft>
        <is-also>
            <doc-id>BCP0208</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8084</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8085</doc-id>
        <title>UDP Usage Guidelines</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>G. Shepherd</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>UDP</kw>
            <kw>guidelines</kw>
        </keywords>
        <abstract><p>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</p><p> Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.</p><p> Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</p><p> This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</p></abstract>
        <draft>draft-ietf-tsvwg-rfc5405bis-19</draft>
        <obsoletes>
            <doc-id>RFC5405</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8899</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0145</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8085</errata-url>
        <doi>10.17487/RFC8085</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8086</doc-id>
        <title>GRE-in-UDP Encapsulation</title>
        <author>
            <name>L. Yong</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Crabbe</name>
        </author>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>T. Herbert</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>This document specifies a method of encapsulating network protocol packets within GRE and UDP headers.  This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field.  This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms.  There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment.  The controlled environment has less restrictive requirements than the general Internet.</p></abstract>
        <draft>draft-ietf-tsvwg-gre-in-udp-encap-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8086</errata-url>
        <doi>10.17487/RFC8086</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8087</doc-id>
        <title>The Benefits of Using Explicit Congestion Notification (ECN)</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ecn</kw>
            <kw>aqm</kw>
            <kw>sctp</kw>
            <kw>tcp</kw>
        </keywords>
        <abstract><p>The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN).  The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking.  It also discusses challenges for successful deployment of ECN.  It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.</p></abstract>
        <draft>draft-ietf-aqm-ecn-benefits-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8087</errata-url>
        <doi>10.17487/RFC8087</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8088</doc-id>
        <title>How to Write an RTP Payload Format</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Payload format</kw>
            <kw>Process</kw>
        </keywords>
        <abstract><p>This document contains information on how best to write an RTP payload format specification.  It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results.  A template is also included with instructions.</p></abstract>
        <draft>draft-ietf-payload-rtp-howto-14</draft>
        <updates>
            <doc-id>RFC2736</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9751</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC8088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8089</doc-id>
        <title>The "file" URI Scheme</title>
        <author>
            <name>M. Kerwin</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>URL</kw>
        </keywords>
        <abstract><p>This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.</p><p> It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.</p></abstract>
        <draft>draft-ietf-appsawg-file-scheme-16</draft>
        <updates>
            <doc-id>RFC1738</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8089</errata-url>
        <doi>10.17487/RFC8089</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8090</doc-id>
        <title>Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.</p></abstract>
        <draft>draft-iab-ccg-appoint-process-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8090</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8091</doc-id>
        <title>A Media Type Structured Syntax Suffix for JSON Text Sequences</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation.  This specification defines and registers "+json-seq" as a structured syntax suffix for JSON text sequences.</p></abstract>
        <draft>draft-wilde-json-seq-suffix-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8091</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8092</doc-id>
        <title>BGP Large Communities Attribute</title>
        <author>
            <name>J. Heitz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Snijders</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>I. Bagdonas</name>
        </author>
        <author>
            <name>N. Hilliard</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>large</kw>
            <kw>communities</kw>
            <kw>four-octet</kw>
        </keywords>
        <abstract><p>This document describes the BGP Large Communities attribute, an extension to BGP-4.  This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management.  The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs.</p></abstract>
        <draft>draft-ietf-idr-large-community-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8092</errata-url>
        <doi>10.17487/RFC8092</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8093</doc-id>
        <title>Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "Deprecated".</p></abstract>
        <draft>draft-ietf-idr-deprecate-30-31-129-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8094</doc-id>
        <title>DNS over Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>P. Patil</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.</p><p> This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.</p></abstract>
        <draft>draft-ietf-dprive-dnsodtls-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <doi>10.17487/RFC8094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8095</doc-id>
        <title>Services Provided by IETF Transport Protocols and Congestion Control Mechanisms</title>
        <author>
            <name>G. Fairhurst</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Trammell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kuehlewind</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>Transmission Control Protocol (TCP)</kw>
            <kw>Multipath TCP (MPTCP)</kw>
            <kw>Stream Control Transmission Protocol (SCTP)</kw>
            <kw>User Datagram Protocol (UDP)</kw>
            <kw>UDP-Lite</kw>
            <kw>Datagram Congestion Control Protocol (DCCP)</kw>
            <kw>Internet Control Message Protocol (ICMP)</kw>
            <kw>Real-Time Transport Protocol (RTP)</kw>
            <kw>File Delivery over Unidirectional Transport/Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast</kw>
            <kw>NACK-Oriented Reliable Multicast (NORM)</kw>
            <kw>Transport Layer Security (TLS)</kw>
            <kw>Datagram TLS (DTLS)</kw>
            <kw>Hypertext Transport Protocol (HTTP)</kw>
            <kw>TAPS</kw>
        </keywords>
        <abstract><p>This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services.  It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport.  This survey provides background for the definition of transport services within the TAPS working group.</p></abstract>
        <draft>draft-ietf-taps-transports-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8095</errata-url>
        <doi>10.17487/RFC8095</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8096</doc-id>
        <title>The IPv6-Specific MIB Modules Are Obsolete</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>65</page-count>
        <abstract><p>In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table.  This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories.  This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic.</p></abstract>
        <draft>draft-ietf-6man-ipv6-mibs-obsolete-02</draft>
        <obsoletes>
            <doc-id>RFC2452</doc-id>
            <doc-id>RFC2454</doc-id>
            <doc-id>RFC2465</doc-id>
            <doc-id>RFC2466</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8096</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8097</doc-id>
        <title>BGP Prefix Origin Validation State Extended Community</title>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system.  Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.</p></abstract>
        <draft>draft-ietf-sidr-origin-validation-signaling-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8097</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8098</doc-id>
        <title>Message Disposition Notification</title>
        <author>
            <name>T. Hansen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>delivery notification</kw>
            <kw>mdn</kw>
        </keywords>
        <abstract><p>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 header fields 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 are 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.</p><p> 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 multiprotocol 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.</p><p> This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement).</p></abstract>
        <draft>draft-ietf-appsawg-mdn-3798bis-16</draft>
        <obsoletes>
            <doc-id>RFC3798</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2046</doc-id>
            <doc-id>RFC3461</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0085</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>appsawg</wg_acronym>
        <doi>10.17487/RFC8098</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8099</doc-id>
        <title>OSPF Topology-Transparent Zone</title>
        <author>
            <name>H. Chen</name>
        </author>
        <author>
            <name>R. Li</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>Z. Liu</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>OSPF</kw>
            <kw>TTZ</kw>
        </keywords>
        <abstract><p>This document presents a Topology-Transparent Zone (TTZ) in an OSPF area.  A TTZ comprises a group of routers and a number of links connecting these routers.  Any router outside of the zone is not aware of the zone.  A TTZ hides the internal topology of the TTZ from the outside.  It does not directly advertise any internal information about the TTZ to a router outside of the TTZ.  The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ.</p></abstract>
        <draft>draft-ietf-ospf-ttz-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC8099</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8100</doc-id>
        <title>Diffserv-Interconnection Classes and Practice</title>
        <author>
            <name>R. Geib</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Diffserv</kw>
            <kw>Interconnection</kw>
            <kw>PHB</kw>
            <kw>Treatment Aggregate</kw>
            <kw>MPLS Short Pipe</kw>
        </keywords>
        <abstract><p>This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation.  Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks.  This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model.  While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.</p></abstract>
        <draft>draft-ietf-tsvwg-diffserv-intercon-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8100</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8101</doc-id>
        <title>IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>J. Axell</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Resource-Priority</kw>
            <kw>namespace</kw>
            <kw>Resource-priorith</kw>
            <kw>3GPP</kw>
            <kw>IMS</kw>
            <kw>MCPTT</kw>
        </keywords>
        <abstract><p>This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.</p></abstract>
        <draft>draft-holmberg-dispatch-mcptt-rp-namespace-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8101</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8102</doc-id>
        <title>Remote-LFA Node Protection and Manageability</title>
        <author>
            <name>P. Sarkar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>LFA</kw>
            <kw>Remote-LFA</kw>
            <kw>IGP</kw>
            <kw>Node Protection</kw>
        </keywords>
        <abstract><p>The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.</p><p> This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.</p></abstract>
        <draft>draft-ietf-rtgwg-rlfa-node-protection-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8102</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8103</doc-id>
        <title>Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>February</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS).  ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.</p></abstract>
        <draft>draft-ietf-curdle-cms-chacha20-poly1305-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8103</errata-url>
        <doi>10.17487/RFC8103</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8104</doc-id>
        <title>Pseudowire (PW) Endpoint Fast Failure Protection</title>
        <author>
            <name>Y. Shen</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>Y. Jiang</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>pseudowire</kw>
            <kw>PW</kw>
            <kw>protection</kw>
            <kw>local repair</kw>
            <kw>fast reroute</kw>
        </keywords>
        <abstract><p>This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure.  Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure.  The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel.  Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.</p></abstract>
        <draft>draft-ietf-pals-endpoint-fast-protection-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8104</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8105</doc-id>
        <title>Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)</title>
        <author>
            <name>P. Mariager</name>
        </author>
        <author>
            <name>J. Petersen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Shelby</name>
        </author>
        <author>
            <name>M. Van de Logt</name>
        </author>
        <author>
            <name>D. Barthel</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>6LoWPAN</kw>
            <kw>ETSI</kw>
            <kw>IoT</kw>
            <kw>and Internet of Things</kw>
        </keywords>
        <abstract><p>Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.</p><p> The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.</p><p> DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.</p><p> This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.</p></abstract>
        <draft>draft-ietf-6lo-dect-ule-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC8105</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8106</doc-id>
        <title>IPv6 Router Advertisement Options for DNS Configuration</title>
        <author>
            <name>J. Jeong</name>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>L. Beloeil</name>
        </author>
        <author>
            <name>S. Madanapalli</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNS Service</kw>
            <kw>DNS Option</kw>
            <kw>Recursive DNS Server Address</kw>
            <kw>DNS Search List</kw>
            <kw>Stateless Autoconfiguration</kw>
        </keywords>
        <abstract><p>This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.</p><p> This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.</p></abstract>
        <draft>draft-ietf-6man-rdnss-rfc6106bis-16</draft>
        <obsoletes>
            <doc-id>RFC6106</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8106</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8107</doc-id>
        <title>Advertising Digital Identifier (Ad-ID) URN Namespace Definition</title>
        <author>
            <name>J. Wold</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms.  This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) "adid" for Ad-IDs.</p></abstract>
        <draft>draft-adid-urn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8107</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8108</doc-id>
        <title>Sending Multiple RTP Streams in a Single RTP Session</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs).  This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session.  This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior.  It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-multi-stream-11</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
            <doc-id>RFC4585</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8108</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8109</doc-id>
        <title>Initializing a DNS Resolver with Priming Queries</title>
        <author>
            <name>P. Koch</name>
        </author>
        <author>
            <name>M. Larson</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes the queries that a DNS resolver should emit to initialize its cache.  The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.</p></abstract>
        <draft>draft-ietf-dnsop-resolver-priming-11</draft>
        <obsoleted-by>
            <doc-id>RFC9609</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8109</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8110</doc-id>
        <title>Opportunistic Wireless Encryption</title>
        <author>
            <name>D. Harkins</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Kumari</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>opportunistic encryption wireless</kw>
        </keywords>
        <abstract><p>This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.</p></abstract>
        <draft>draft-harkins-owe-07</draft>
        <updated-by>
            <doc-id>RFC9672</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8110</errata-url>
        <doi>10.17487/RFC8110</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8111</doc-id>
        <title>Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)</title>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <author>
            <name>V. Ermagan</name>
        </author>
        <author>
            <name>A. Jain</name>
        </author>
        <author>
            <name>A. Smirnov</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>LISP</kw>
            <kw>DDT</kw>
            <kw>EID</kw>
            <kw>Locator</kw>
            <kw>Mapping System</kw>
            <kw>Map-Server</kw>
            <kw>Map-Referral</kw>
            <kw>Referral</kw>
        </keywords>
        <abstract><p>This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs).  It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT nodes".  Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.</p></abstract>
        <draft>draft-ietf-lisp-ddt-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC8111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8112</doc-id>
        <title>Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>A. Jain</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>A simple tool called the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP- DDT hierarchy.  This document describes how the "rig" tool works.</p></abstract>
        <draft>draft-farinacci-lisp-rig-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8112</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8113</doc-id>
        <title>Locator/ID Separation Protocol (LISP): Shared Extension Message &amp; IANA Registry for Packet Type Allocations</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Shared Experiment Code</kw>
            <kw>LISP codepoints</kw>
            <kw>Experiment Identifier</kw>
            <kw>Experiment ID</kw>
            <kw>LISP Experimental Registry</kw>
            <kw>LISP Extension</kw>
            <kw>Extending LISP</kw>
        </keywords>
        <abstract><p>This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension.  It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.</p></abstract>
        <draft>draft-ietf-lisp-type-iana-06</draft>
        <obsoleted-by>
            <doc-id>RFC9304</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6830</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC8113</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8114</doc-id>
        <title>Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>C. Qin</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>Q. Wang</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>DS-Lite</kw>
            <kw>IPv4-IPv6 Interconnection</kw>
            <kw>PREFIX64</kw>
            <kw>SSM</kw>
            <kw>ASM</kw>
            <kw>IPv4 service continuity</kw>
            <kw>Multicast service continuity</kw>
            <kw>IPv6-only</kw>
            <kw>IPv6-only multicast</kw>
            <kw>PIM</kw>
            <kw>MLD</kw>
            <kw>IGMP</kw>
            <kw>A+P</kw>
            <kw>MAP</kw>
            <kw>MAP-E</kw>
            <kw>address-sharing</kw>
            <kw>CGN</kw>
            <kw>NAT64</kw>
            <kw>IPv4 over IPv6</kw>
            <kw>IPv6 Address Synthesis</kw>
            <kw>Any-Source Multicast</kw>
            <kw>Source-Specific Multicast</kw>
        </keywords>
        <abstract><p>This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network.  The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic.  The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).</p></abstract>
        <draft>draft-ietf-softwire-dslite-multicast-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8114</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8115</doc-id>
        <title>DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>J. Qin</name>
        </author>
        <author>
            <name>T. Tsou</name>
        </author>
        <author>
            <name>X. Deng</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>PREFIX64</kw>
            <kw>SSM</kw>
            <kw>ASM</kw>
            <kw>Prefix Discovery</kw>
            <kw>IPv4-Converted IPv6 Addresses</kw>
            <kw>IPv4 service continuity</kw>
            <kw>IPv6 Address Synthesis</kw>
            <kw>Any-Source Multicast</kw>
            <kw>Source-Specific Multicast</kw>
            <kw>PIM</kw>
            <kw>IPv4-IPv6 interconnection</kw>
            <kw>IPv4  over IPv6</kw>
            <kw>A+P</kw>
            <kw>MAP</kw>
            <kw>MAP-E</kw>
            <kw>address-sharing</kw>
            <kw>CGN</kw>
            <kw>NAT64</kw>
        </keywords>
        <abstract><p>This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.</p></abstract>
        <draft>draft-ietf-softwire-multicast-prefix-option-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8115</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8116</doc-id>
        <title>Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>J. Yi</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>MANET</kw>
        </keywords>
        <abstract><p>This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations.  It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated.</p></abstract>
        <draft>draft-ietf-manet-olsrv2-sec-threats-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8116</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8117</doc-id>
        <title>Current Hostname Practice Considered Harmful</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>R. Winter</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.</p><p> There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.</p></abstract>
        <draft>draft-ietf-intarea-hostname-practice-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC8117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8118</doc-id>
        <title>The application/pdf Media Type</title>
        <author>
            <name>M. Hardy</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>D. Markovic</name>
        </author>
        <author>
            <name>D. Johnson</name>
        </author>
        <author>
            <name>M. Bailey</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Portable Document Format</kw>
            <kw>MIME type</kw>
        </keywords>
        <abstract><p>The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993.  This document provides an overview of the PDF format and updates the media type registration of "application/pdf".  It obsoletes RFC 3778.</p></abstract>
        <draft>draft-hardy-pdf-mime-05</draft>
        <obsoletes>
            <doc-id>RFC3778</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8119</doc-id>
        <title>SIP "cause" URI Parameter for Service Number Translation</title>
        <author>
            <name>M. Mohali</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Cause</kw>
        </keywords>
        <abstract><p>RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message.  This document updates RFC 4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number.  This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.</p></abstract>
        <draft>draft-mohali-dispatch-cause-for-service-number-14</draft>
        <updates>
            <doc-id>RFC4458</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8120</doc-id>
        <title>Mutual Authentication Protocol for HTTP</title>
        <author>
            <name>Y. Oiwa</name>
        </author>
        <author>
            <name>H. Watanabe</name>
        </author>
        <author>
            <name>H. Takagi</name>
        </author>
        <author>
            <name>K. Maeda</name>
        </author>
        <author>
            <name>T. Hayashi</name>
        </author>
        <author>
            <name>Y. Ioku</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol.  This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication.  Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.</p></abstract>
        <draft>draft-ietf-httpauth-mutual-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <doi>10.17487/RFC8120</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8121</doc-id>
        <title>Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)</title>
        <author>
            <name>Y. Oiwa</name>
        </author>
        <author>
            <name>H. Watanabe</name>
        </author>
        <author>
            <name>H. Takagi</name>
        </author>
        <author>
            <name>K. Maeda</name>
        </author>
        <author>
            <name>T. Hayashi</name>
        </author>
        <author>
            <name>Y. Ioku</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).</p></abstract>
        <draft>draft-ietf-httpauth-mutual-algo-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>httpauth</wg_acronym>
        <doi>10.17487/RFC8121</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8122</doc-id>
        <title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>TLS</kw>
            <kw>Fingerprint</kw>
            <kw>Offer</kw>
            <kw>Answer</kw>
        </keywords>
        <abstract><p>This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</p><p> This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.</p></abstract>
        <draft>draft-ietf-mmusic-4572-update-13</draft>
        <obsoletes>
            <doc-id>RFC4572</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8844</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8122</errata-url>
        <doi>10.17487/RFC8122</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8123</doc-id>
        <title>Requirements for Marking SIP Messages to be Logged</title>
        <author>
            <name>P. Dawes</name>
        </author>
        <author>
            <name>C. Arunachalam</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>logme</kw>
            <kw>troubleshooting</kw>
            <kw>debug</kw>
            <kw>logging</kw>
        </keywords>
        <abstract><p>SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.</p><p> This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.</p></abstract>
        <draft>draft-ietf-insipid-logme-reqs-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>insipid</wg_acronym>
        <doi>10.17487/RFC8123</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8124</doc-id>
        <title>The Session Description Protocol (SDP) WebSocket Connection URI Attribute</title>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Secure WebSocket</kw>
            <kw>Uniform Resource Identifier</kw>
        </keywords>
        <abstract><p>The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications.  This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.</p></abstract>
        <draft>draft-ietf-bfcpbis-sdp-ws-uri-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>bfcpbis</wg_acronym>
        <doi>10.17487/RFC8124</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8125</doc-id>
        <title>Requirements for Password-Authenticated Key Agreement (PAKE) Schemes</title>
        <author>
            <name>J. Schmidt</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Password</kw>
            <kw>Key Agreement</kw>
            <kw>Password-Authenticated Key Agreement</kw>
            <kw>Cryptographic Protocol</kw>
        </keywords>
        <abstract><p>Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password.  This document reviews different types of PAKE schemes.  Furthermore, it presents requirements and gives recommendations to designers of new schemes.  It is a product of the Crypto Forum Research Group (CFRG).</p></abstract>
        <draft>draft-irtf-cfrg-pake-reqs-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8125</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8126</doc-id>
        <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>B. Leiba</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>internet assigned numbers authority</kw>
            <kw>values</kw>
            <kw>implementations</kw>
            <kw>code point</kw>
            <kw>protocol constant</kw>
            <kw>protocol parameter</kw>
            <kw>codepoint</kw>
        </keywords>
        <abstract><p>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</p><p> To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</p><p> This is the third edition of this document; it obsoletes RFC 5226.</p></abstract>
        <draft>draft-leiba-cotton-iana-5226bis-20</draft>
        <obsoletes>
            <doc-id>RFC5226</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0026</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8126</errata-url>
        <doi>10.17487/RFC8126</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8127</doc-id>
        <title>Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor</title>
        <author>
            <name>D. Patki</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>Q. Fu</name>
        </author>
        <author>
            <name>L. Bertz</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Binding Refresh</kw>
            <kw>Heartbeat</kw>
        </keywords>
        <abstract><p>This specification defines a new extension, LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6.  This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters.</p></abstract>
        <draft>draft-ietf-dmm-lma-controlled-mag-params-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8128</doc-id>
        <title>IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee</title>
        <author>
            <name>C. Morgan</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).</p></abstract>
        <draft>draft-iab-rzerc-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8128</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8129</doc-id>
        <title>Authentication Indicator in Kerberos Tickets</title>
        <author>
            <name>A. Jain</name>
        </author>
        <author>
            <name>N. Kinder</name>
        </author>
        <author>
            <name>N. McCallum</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document updates RFC 4120, as it specifies an extension in the Kerberos protocol.  It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR.  The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.</p></abstract>
        <draft>draft-ietf-kitten-krb-auth-indicator-07</draft>
        <updates>
            <doc-id>RFC4120</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC8129</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8130</doc-id>
        <title>RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec</title>
        <author>
            <name>V. Demjanenko</name>
        </author>
        <author>
            <name>D. Satterlee</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>MELP</kw>
            <kw>MELPe</kw>
            <kw>MELP2400</kw>
            <kw>MELP1200</kw>
            <kw>MELP600</kw>
            <kw>SCIP-210</kw>
            <kw>SCIP210</kw>
        </keywords>
        <abstract><p>This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder.  MELPe's three different speech encoding rates and sample frame sizes are supported.  Comfort noise procedures and packet loss concealment are described in detail.</p></abstract>
        <draft>draft-ietf-payload-melpe-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC8130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8131</doc-id>
        <title>RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing</title>
        <author>
            <name>X. Zhang</name>
        </author>
        <author>
            <name>H. Zheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>P. Brzozowski</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Association Object</kw>
            <kw>LSP Reversion</kw>
            <kw>LSP Recovery</kw>
            <kw>GMPLS Make-Before-Break</kw>
            <kw>GMPLS 1+R</kw>
            <kw>GMPLS 1+1+R</kw>
        </keywords>
        <abstract><p>In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.</p><p> This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.</p></abstract>
        <draft>draft-ietf-teas-gmpls-resource-sharing-proc-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8131</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8132</doc-id>
        <title>PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>P. van der Stok</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>A. Sehgal</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>CoAP</kw>
        </keywords>
        <abstract><p>The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.</p><p> This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.</p></abstract>
        <draft>draft-ietf-core-etch-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8132</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8133</doc-id>
        <title>The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol</title>
        <author>
            <name>S. Smyshlyaev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Alekseev</name>
        </author>
        <author>
            <name>I. Oshkin</name>
        </author>
        <author>
            <name>V. Popov</name>
        </author>
        <date>
            <month>March</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>cryptography</kw>
            <kw>secure channel</kw>
            <kw>elliptic curve</kw>
        </keywords>
        <abstract><p>This document describes the Security Evaluated Standardized Password- Authenticated Key Exchange (SESPAKE) protocol.  The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information.  The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects.</p></abstract>
        <draft>draft-smyshlyaev-sespake-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8134</doc-id>
        <title>Management Incident Lightweight Exchange (MILE) Implementation Report</title>
        <author>
            <name>C. Inacio</name>
        </author>
        <author>
            <name>D. Miyamoto</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IODEF</kw>
            <kw>RID</kw>
            <kw>SCI</kw>
            <kw>INCH</kw>
            <kw>MILE</kw>
            <kw>Implementation</kw>
        </keywords>
        <abstract><p>This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups.</p></abstract>
        <draft>draft-ietf-mile-implementreport-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC8134</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8135</doc-id>
        <title>Complex Addressing in IPv6</title>
        <author>
            <name>M. Danielson</name>
        </author>
        <author>
            <name>M. Nilsson</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world.  It also allows for new and improved security measures and supports advanced cloud computing challenges.</p></abstract>
        <draft>draft-danielson-complexaddress-latest-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8135</errata-url>
        <doi>10.17487/RFC8135</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8136</doc-id>
        <title>Additional Transition Functionality for IPv6</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.</p></abstract>
        <draft>draft-carpenter-addtransfunc-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8136</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8137</doc-id>
        <title>IEEE 802.15.4 Information Element for the IETF</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>P. Kinney</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IE</kw>
        </keywords>
        <abstract><p>IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner.  The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements.  This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.</p></abstract>
        <draft>draft-kivinen-802-15-ie-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8137</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8138</doc-id>
        <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <author>
            <name>R. Cragie</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550).  Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.</p></abstract>
        <draft>draft-ietf-roll-routing-dispatch-05</draft>
        <updated-by>
            <doc-id>RFC9008</doc-id>
            <doc-id>RFC9035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8138</errata-url>
        <doi>10.17487/RFC8138</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8139</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>M. Umair</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <author>
            <name>F. Hu</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>DRB</kw>
            <kw>VLAN mapping</kw>
            <kw>inhibition</kw>
            <kw>port shutdown</kw>
            <kw>trill</kw>
            <kw>TRansparent Interconnection of Lots of Links</kw>
        </keywords>
        <abstract><p>TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached.  Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch.  This document clarifies and updates the Appointed Forwarder mechanism.  It updates RFCs 6325 and 7177 and obsoletes RFC 6439.</p></abstract>
        <draft>draft-ietf-trill-rfc6439bis-05</draft>
        <obsoletes>
            <doc-id>RFC6439</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC6325</doc-id>
            <doc-id>RFC7177</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8139</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8140</doc-id>
        <title>The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.</p><p> Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".</p><p> This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.</p></abstract>
        <draft>draft-farrel-ascii-art-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8140</errata-url>
        <doi>10.17487/RFC8140</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8141</doc-id>
        <title>Uniform Resource Names (URNs)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Uniform Resource Name</kw>
            <kw>URN</kw>
            <kw>Uniform Resource Identifier</kw>
            <kw>URI</kw>
        </keywords>
        <abstract><p>A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier.  With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance.  With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA).  This document obsoletes both RFCs 2141 and 3406.</p></abstract>
        <draft>draft-ietf-urnbis-rfc2141bis-urn-22</draft>
        <obsoletes>
            <doc-id>RFC2141</doc-id>
            <doc-id>RFC3406</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>urnbis</wg_acronym>
        <doi>10.17487/RFC8141</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8142</doc-id>
        <title>GeoJSON Text Sequences</title>
        <author>
            <name>S. Gillies</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>Geospatial</kw>
            <kw>JavaScript Object Notation</kw>
        </keywords>
        <abstract><p>This document describes the GeoJSON text sequence format and "application/geo+json-seq" media type.  This format is based on JavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.</p></abstract>
        <draft>draft-ietf-geojson-text-sequence-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>geojson</wg_acronym>
        <doi>10.17487/RFC8142</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8143</doc-id>
        <title>Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)</title>
        <author>
            <name>J. Elie</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NNTP</kw>
            <kw>Usenet</kw>
            <kw>NetNews</kw>
            <kw>TLS</kw>
            <kw>STARTTLS</kw>
        </keywords>
        <abstract><p>This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS).  It modernizes the NNTP usage of TLS to be consistent with TLS best current practices.  This document updates RFC 4642.</p></abstract>
        <draft>draft-elie-nntp-tls-recommendations-05</draft>
        <updates>
            <doc-id>RFC4642</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8143</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8144</doc-id>
        <title>Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>http</kw>
            <kw>prefer</kw>
            <kw>webav</kw>
            <kw>caldav</kw>
        </keywords>
        <abstract><p>This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request.  Furthermore, it defines the new "depth-noroot" preference.</p></abstract>
        <draft>draft-murchison-webdav-prefer-14</draft>
        <updates>
            <doc-id>RFC7240</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8144</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8145</doc-id>
        <title>Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)</title>
        <author>
            <name>D. Wessels</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>Trust Anchor</kw>
        </keywords>
        <abstract><p>The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust.  The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.</p></abstract>
        <draft>draft-ietf-dnsop-edns-key-tag-05</draft>
        <updated-by>
            <doc-id>RFC8553</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8145</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8146</doc-id>
        <title>Adding Support for Salted Password Databases to EAP-pwd</title>
        <author>
            <name>D. Harkins</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Password-Authenticated Key Exchange</kw>
            <kw>PAKE</kw>
            <kw>Dictionary Attack</kw>
            <kw>Authentication EAP</kw>
        </keywords>
        <abstract><p>EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks.  It includes support for raw keys and double hashing of a password in the style of Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords.  There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.</p></abstract>
        <draft>draft-harkins-salted-eap-pwd-08</draft>
        <updates>
            <doc-id>RFC5931</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8146</errata-url>
        <doi>10.17487/RFC8146</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8147</doc-id>
        <title>Next-Generation Pan-European eCall</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>emergency</kw>
            <kw>call</kw>
            <kw>calls</kw>
            <kw>emergency call</kw>
            <kw>emergency calls</kw>
            <kw>vehicle</kw>
            <kw>acn</kw>
            <kw>aacn</kw>
            <kw>automatic crash notification</kw>
            <kw>automatic collision notification</kw>
            <kw>advanced automatic crash notification</kw>
            <kw>advanced automatic collision notification</kw>
            <kw>crash</kw>
            <kw>vehicle-initiated</kw>
        </keywords>
        <abstract><p>This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in-vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.</p><p> This document also registers MIME media types and an Emergency Call Data Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.</p><p> Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.</p></abstract>
        <draft>draft-ietf-ecrit-ecall-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8147</errata-url>
        <doi>10.17487/RFC8147</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8148</doc-id>
        <title>Next-Generation Vehicle-Initiated Emergency Calls</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>emergency</kw>
            <kw>call</kw>
            <kw>calls</kw>
            <kw>emergency call</kw>
            <kw>emergency calls</kw>
            <kw>vehicle</kw>
            <kw>acn</kw>
            <kw>aacn</kw>
            <kw>automatic crash notification</kw>
            <kw>automatic collision notification</kw>
            <kw> advanced automatic crash notification</kw>
            <kw>advanced automatic collision notification</kw>
            <kw>crash</kw>
            <kw>vehicle-initiated</kw>
            <kw>ecall</kw>
        </keywords>
        <abstract><p>This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.</p><p> This document also registers a MIME media type and Emergency Call Data Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.</p><p> This document reuses the technical aspects of next-generation Pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions). However, this document specifies use of a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context.</p></abstract>
        <draft>draft-ietf-ecrit-car-crash-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ecrit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8148</errata-url>
        <doi>10.17487/RFC8148</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8149</doc-id>
        <title>RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)</title>
        <author>
            <name>T. Saad</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>R. Venator</name>
        </author>
        <author>
            <name>Y. Kamite</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RSVP fragmentation</kw>
            <kw>RSVP fragment identifier</kw>
            <kw>P2MP-TE tree reoptimization</kw>
            <kw>P2MP-TE tree re-evaluation</kw>
            <kw>Preferable P2MP-TE tree</kw>
            <kw>Inter-domain P2MP-TE</kw>
        </keywords>
        <abstract><p>The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method.  This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them.  When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented.  This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.</p></abstract>
        <draft>draft-ietf-teas-p2mp-loose-path-reopt-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8149</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8150</doc-id>
        <title>MPLS Transport Profile Linear Protection MIB</title>
        <author>
            <name>S. Kingston Smiler</name>
        </author>
        <author>
            <name>M. Venkatesan</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>J. Ryoo</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Management Information Base</kw>
            <kw>MIB</kw>
            <kw>SMIv2</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it defines objects for managing Multiprotocol Label Switching - Transport Profile (MPLS-TP) linear protection.</p></abstract>
        <draft>draft-ietf-mpls-tp-linear-protection-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8150</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8151</doc-id>
        <title>Use Cases for Data Center Network Virtualization Overlay Networks</title>
        <author>
            <name>L. Yong</name>
        </author>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>M. Toy</name>
        </author>
        <author>
            <name>A. Isaac</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications.</p></abstract>
        <draft>draft-ietf-nvo3-use-case-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC8151</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8152</doc-id>
        <title>CBOR Object Signing and Encryption (COSE)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>121</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>ECC</kw>
            <kw>Elliptic Curve</kw>
        </keywords>
        <abstract><p>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format.  This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</p></abstract>
        <draft>draft-ietf-cose-msg-24</draft>
        <obsoleted-by>
            <doc-id>RFC9052</doc-id>
            <doc-id>RFC9053</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8152</errata-url>
        <doi>10.17487/RFC8152</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8153</doc-id>
        <title>Digital Preservation Considerations for the RFC Series</title>
        <author>
            <name>H. Flanagan</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>archive</kw>
            <kw>archiving</kw>
        </keywords>
        <abstract><p>The RFC Editor is both the publisher and the archivist for the RFC Series.  This document applies specifically to the archivist role of the RFC Editor.  It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary.  This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.</p></abstract>
        <draft>draft-iab-rfc-preservation-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8154</doc-id>
        <title>Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout</title>
        <author>
            <name>C. Hellwig</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file.  The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices.</p></abstract>
        <draft>draft-ietf-nfsv4-scsi-layout-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8154</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8155</doc-id>
        <title>Traversal Using Relays around NAT (TURN) Server Auto Discovery</title>
        <author>
            <name>P. Patil</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.</p><p> This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.</p></abstract>
        <draft>draft-ietf-tram-turn-server-discovery-12</draft>
        <updates>
            <doc-id>RFC5766</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <doi>10.17487/RFC8155</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8156</doc-id>
        <title>DHCPv6 Failover Protocol</title>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>K. Kinnear</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Failover</kw>
        </keywords>
        <abstract><p>DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC 3315) does not offer server redundancy.  This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition.  It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031).</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-failover-protocol-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8156</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8157</doc-id>
        <title>Huawei's GRE Tunnel Bonding Protocol</title>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>C. Heidemann</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>M. Cullen</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Hybrid Access</kw>
            <kw>Bandwidth Aggregation</kw>
            <kw>Bonding Tunnel</kw>
            <kw>GRE Channel</kw>
            <kw>Hybrid Access Aggregation Point</kw>
            <kw>Home Gateway</kw>
        </keywords>
        <abstract><p>There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.</p><p> In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.</p></abstract>
        <draft>draft-zhang-gre-tunnel-bonding-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8157</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8158</doc-id>
        <title>IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events</title>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>template</kw>
        </keywords>
        <abstract><p>Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing.  In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting.  Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior.  This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information.  This document describes the formats for logging NAT events.</p></abstract>
        <draft>draft-ietf-behave-ipfix-nat-logging-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8159</doc-id>
        <title>Keyed IPv6 Tunnel</title>
        <author>
            <name>M. Konstantynowicz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Heron</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Schatzmayr</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>L2TPv3</kw>
            <kw>pseudowire</kw>
        </keywords>
        <abstract><p>This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses.  The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.</p></abstract>
        <draft>draft-ietf-l2tpext-keyed-ipv6-tunnel-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>l2tpext</wg_acronym>
        <doi>10.17487/RFC8159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8160</doc-id>
        <title>IUTF8 Terminal Mode in Secure Shell (SSH)</title>
        <author>
            <name>S. Tatham</name>
        </author>
        <author>
            <name>D. Tucker</name>
        </author>
        <date>
            <month>April</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Secure Shell</kw>
            <kw>SSH</kw>
        </keywords>
        <abstract><p>This document specifies a new opcode in the Secure Shell terminal modes encoding.  The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding.</p></abstract>
        <draft>draft-sgtatham-secsh-iutf8-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8160</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8161</doc-id>
        <title>Benchmarking the Neighbor Discovery Protocol</title>
        <author>
            <name>W. Cerveny</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Scaling</kw>
            <kw>NDP</kw>
        </keywords>
        <abstract><p>This document provides benchmarking procedures for the Neighbor Discovery Protocol (NDP).  It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.</p></abstract>
        <draft>draft-ietf-bmwg-ipv6-nd-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8162</doc-id>
        <title>Using Secure DNS to Associate Certificates with Domain Names for S/MIME</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>J. Schlyter</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.</p></abstract>
        <draft>draft-ietf-dane-smime-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dane</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8162</errata-url>
        <doi>10.17487/RFC8162</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8163</doc-id>
        <title>Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks</title>
        <author>
            <name>K. Lynn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Martocci</name>
        </author>
        <author>
            <name>C. Neilson</name>
        </author>
        <author>
            <name>S. Donaldson</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <abstract><p>Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks.  This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.</p></abstract>
        <draft>draft-ietf-6lo-6lobac-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8163</errata-url>
        <doi>10.17487/RFC8163</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8164</doc-id>
        <title>Opportunistic Security for HTTP/2</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Opportunistic Security</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks.  This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.</p></abstract>
        <draft>draft-ietf-httpbis-http2-encryption-11</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8164</errata-url>
        <doi>10.17487/RFC8164</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8165</doc-id>
        <title>Design Considerations for Metadata Insertion</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>surveillance</kw>
            <kw>proxy</kw>
            <kw>proxying</kw>
            <kw>middlebox</kw>
        </keywords>
        <abstract><p>The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications.  This document considers the implications of protocol designs that associate metadata with encrypted flows.  In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.</p></abstract>
        <draft>draft-hardie-privsec-metadata-insertion-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8165</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8166</doc-id>
        <title>Remote Direct Memory Access Transport for Remote Procedure Call Version 1</title>
        <author>
            <name>C. Lever</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <author>
            <name>T. Talpey</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>RPC-over-RDMA</kw>
        </keywords>
        <abstract><p>This document specifies a protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA).  This protocol is referred to as the RPC-over- RDMA version 1 protocol in this document.  It requires no revision to application RPC protocols or the RPC protocol itself.  This document obsoletes RFC 5666.</p></abstract>
        <draft>draft-ietf-nfsv4-rfc5666bis-11</draft>
        <obsoletes>
            <doc-id>RFC5666</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8797</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8166</errata-url>
        <doi>10.17487/RFC8166</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8167</doc-id>
        <title>Bidirectional Remote Procedure Call on RPC-over-RDMA Transports</title>
        <author>
            <name>C. Lever</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NFS-over-RDMA</kw>
            <kw>RPC-over-RDMA</kw>
        </keywords>
        <abstract><p>Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection.  This document describes how RPC transport endpoints capable of Remote Direct Memory Access (RDMA) convey RPCs in both directions on a single connection.</p></abstract>
        <draft>draft-ietf-nfsv4-rpcrdma-bidirection-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8167</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8168</doc-id>
        <title>DHCPv6 Prefix-Length Hint Issues</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>C. Liu</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>Dynamic Host Configuration Protocol</kw>
            <kw>IPv6</kw>
            <kw>Prefix</kw>
            <kw>Prefix Delegation</kw>
            <kw>Prefix Length</kw>
            <kw>Hint</kw>
            <kw>Address Allocation</kw>
        </keywords>
        <abstract><p>DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint.  This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8169</doc-id>
        <title>Residence Time Measurement in MPLS Networks</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>S. Ruffini</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>A. Vainshtein</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>G-ACh</kw>
            <kw>Resident Time</kw>
            <kw>MPLS</kw>
        </keywords>
        <abstract><p>This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.</p><p> Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message.</p></abstract>
        <draft>draft-ietf-mpls-residence-time-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8169</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8170</doc-id>
        <title>Planning for Protocol Adoption and Subsequent Transitions</title>
        <author>
            <name>D. Thaler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>transition plan</kw>
        </keywords>
        <abstract><p>Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol.  Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult.  This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.</p></abstract>
        <draft>draft-iab-protocol-transitions-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8170</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8171</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>Push</kw>
            <kw>Pull</kw>
            <kw>ESADI</kw>
            <kw>ES-IS</kw>
        </keywords>
        <abstract><p>This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches.  The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding.  It can also be used to detect traffic with forged source addresses.</p></abstract>
        <draft>draft-ietf-trill-directory-assist-mechanisms-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8171</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8172</doc-id>
        <title>Considerations for Benchmarking Virtual Network Functions and Their Infrastructure</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions.  This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware.</p></abstract>
        <draft>draft-ietf-bmwg-virtual-net-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8172</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8173</doc-id>
        <title>Precision Time Protocol Version 2 (PTPv2) Management Information Base</title>
        <author>
            <name>V. Shankarkumar</name>
        </author>
        <author>
            <name>L. Montini</name>
        </author>
        <author>
            <name>T. Frost</name>
        </author>
        <author>
            <name>G. Dowd</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.</p><p> This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions.</p></abstract>
        <draft>draft-ietf-tictoc-ptp-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tictoc</wg_acronym>
        <doi>10.17487/RFC8173</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8174</doc-id>
        <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</p></abstract>
        <draft>draft-leiba-rfc2119-update-02</draft>
        <updates>
            <doc-id>RFC2119</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0014</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8174</errata-url>
        <doi>10.17487/RFC8174</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8175</doc-id>
        <title>Dynamic Link Exchange Protocol (DLEP)</title>
        <author>
            <name>S. Ratliff</name>
        </author>
        <author>
            <name>S. Jury</name>
        </author>
        <author>
            <name>D. Satterwhite</name>
        </author>
        <author>
            <name>R. Taylor</name>
        </author>
        <author>
            <name>B. Berry</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <abstract><p>When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.</p></abstract>
        <draft>draft-ietf-manet-dlep-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8175</errata-url>
        <doi>10.17487/RFC8175</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8176</doc-id>
        <title>Authentication Method Reference Values</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>P. Hunt</name>
        </author>
        <author>
            <name>A. Nadalin</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Authentication Method Reference</kw>
            <kw>Authentication Method,</kw>
        </keywords>
        <abstract><p>The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined.  This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.</p></abstract>
        <draft>draft-ietf-oauth-amr-values-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8176</errata-url>
        <doi>10.17487/RFC8176</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8177</doc-id>
        <title>YANG Data Model for Key Chains</title>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>D. Yeung</name>
        </author>
        <author>
            <name>I. Chen</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document describes the key chain YANG data model.  Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys.  A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm.  By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated.  By representing them in a YANG data model, key distribution can be automated.</p></abstract>
        <draft>draft-ietf-rtgwg-yang-key-chain-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8177</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8178</doc-id>
        <title>Rules for NFSv4 Extensions and Minor Versions</title>
        <author>
            <name>D. Noveck</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document describes the rules relating to the extension of the NFSv4 family of protocols.  It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards.  The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.</p></abstract>
        <draft>draft-ietf-nfsv4-versioning-11</draft>
        <updates>
            <doc-id>RFC5661</doc-id>
            <doc-id>RFC7862</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8178</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8179</doc-id>
        <title>Intellectual Property Rights in IETF Technology</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>J. Contreras</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IPR</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract><p>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 as possible about any IPR constraints on a technical proposal as early as possible in the development process.  The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders.  This document sets out 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 document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.  This document also obsoletes RFCs 3979 and 4879.</p></abstract>
        <draft>draft-bradner-rfc3979bis-13</draft>
        <obsoletes>
            <doc-id>RFC3979</doc-id>
            <doc-id>RFC4879</doc-id>
        </obsoletes>
        <updates>
            <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>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8179</errata-url>
        <doi>10.17487/RFC8179</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8180</doc-id>
        <title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration</title>
        <author>
            <name>X. Vilajosana</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Pister</name>
        </author>
        <author>
            <name>T. Watteyne</name>
        </author>
        <date>
            <month>May</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network.  This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network.  6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links.  This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH.  This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH.  This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.</p></abstract>
        <draft>draft-ietf-6tisch-minimal-21</draft>
        <is-also>
            <doc-id>BCP0210</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8180</errata-url>
        <doi>10.17487/RFC8180</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8181</doc-id>
        <title>A Publication Protocol for the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>A. Sonalker</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SIDR</kw>
        </keywords>
        <abstract><p>This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects.  Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects.  Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository.  This document defines a protocol which addresses these needs.</p></abstract>
        <draft>draft-ietf-sidr-publication-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8181</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8182</doc-id>
        <title>The RPKI Repository Delta Protocol (RRDP)</title>
        <author>
            <name>T. Bruijnzeels</name>
        </author>
        <author>
            <name>O. Muravskiy</name>
        </author>
        <author>
            <name>B. Weber</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories.  Relying Parties retrieve the published information from those repositories.  This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose.  RRDP was specifically designed for scaling.  It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.</p></abstract>
        <draft>draft-ietf-sidr-delta-protocol-08</draft>
        <updated-by>
            <doc-id>RFC9674</doc-id>
            <doc-id>RFC9697</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8182</errata-url>
        <doi>10.17487/RFC8182</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8183</doc-id>
        <title>An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services</title>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>RPKI</kw>
        </keywords>
        <abstract><p>This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.</p><p> This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships.</p></abstract>
        <draft>draft-ietf-sidr-rpki-oob-setup-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8183</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8184</doc-id>
        <title>Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires</title>
        <author>
            <name>W. Cheng</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>S. Davari</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>mpls-tp</kw>
        </keywords>
        <abstract><p>This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used.  A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs.  This PW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.</p></abstract>
        <draft>draft-ietf-pals-mpls-tp-dual-homing-protection-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8184</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8185</doc-id>
        <title>Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection</title>
        <author>
            <name>W. Cheng</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>mpls</kw>
            <kw>mpls-tp</kw>
        </keywords>
        <abstract><p>In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs) (RFC 5921) may be statically configured when a dynamic control plane is not available.  A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the Packet Switched Network (PSN).  The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184.  This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection.</p></abstract>
        <draft>draft-ietf-pals-mpls-tp-dual-homing-coordination-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8185</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8186</doc-id>
        <title>Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>I. Meilik</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>TWAMP</kw>
            <kw>IEEE 1588</kw>
            <kw>PTPv2</kw>
        </keywords>
        <abstract><p>This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.</p></abstract>
        <draft>draft-ietf-ippm-twamp-time-format-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8186</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8187</doc-id>
        <title>Indicating Character Encoding and Language for HTTP Header Field Parameters</title>
        <author>
            <name>J. Reschke</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.</p><p> This document obsoletes RFC 5987.</p></abstract>
        <draft>draft-ietf-httpbis-rfc5987bis-05</draft>
        <obsoletes>
            <doc-id>RFC5987</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8187</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8188</doc-id>
        <title>Encrypted Content-Encoding for HTTP</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>http</kw>
            <kw>content coding</kw>
            <kw>content encoding</kw>
            <kw>encryption aead</kw>
        </keywords>
        <abstract><p>This memo introduces a content coding for HTTP that allows message payloads to be encrypted.</p></abstract>
        <draft>draft-ietf-httpbis-encryption-encoding-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8188</errata-url>
        <doi>10.17487/RFC8188</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8189</doc-id>
        <title>Multi-Cost Application-Layer Traffic Optimization (ALTO)</title>
        <author>
            <name>S. Randriamasy</name>
        </author>
        <author>
            <name>W. Roome</name>
        </author>
        <author>
            <name>N. Schwan</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>ALTO Information Resources</kw>
            <kw>Network Map</kw>
            <kw>PID</kw>
            <kw>Filtered Network Map</kw>
            <kw>Endpoint Property Service</kw>
            <kw>Endpoint Cost Service</kw>
            <kw>Multi-Cost</kw>
            <kw>Filtered Multi-Cost Map</kw>
            <kw>Multi-Cost Data Format</kw>
            <kw>Testable Cost Types</kw>
            <kw>or-constraints</kw>
        </keywords>
        <abstract><p>The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.</p><p> This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.</p></abstract>
        <draft>draft-ietf-alto-multi-cost-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC8189</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8190</doc-id>
        <title>Updates to the Special-Purpose IP Address Registries</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>M. Cotton</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>L. Vegoda</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.</p><p> This memo updates RFC 6890.</p></abstract>
        <draft>draft-bchv-rfc6890bis-07</draft>
        <updates>
            <doc-id>RFC6890</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0153</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8191</doc-id>
        <title>Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)</title>
        <author>
            <name>Z. Yan</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>X. Lee</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PMIPv6</kw>
            <kw>HNP</kw>
            <kw>HNP renumbering</kw>
            <kw>LMA handover</kw>
        </keywords>
        <abstract><p>In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP.  During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA.  However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.).  In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.</p></abstract>
        <draft>draft-ietf-dmm-hnprenum-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8191</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8192</doc-id>
        <title>Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>M. Zarny</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>R. Kumar</name>
        </author>
        <author>
            <name>J. Jeong</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>I2NSF</kw>
        </keywords>
        <abstract><p>This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.</p></abstract>
        <draft>draft-ietf-i2nsf-problem-and-use-cases-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>i2nsf</wg_acronym>
        <doi>10.17487/RFC8192</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8193</doc-id>
        <title>Information Model for Large-Scale Measurement Platforms (LMAPs)</title>
        <author>
            <name>T. Burbridge</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>This Information Model applies to the Measurement Agent within an LMAP framework.  As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework.  The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols.</p></abstract>
        <draft>draft-ietf-lmap-information-model-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lmap</wg_acronym>
        <doi>10.17487/RFC8193</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8194</doc-id>
        <title>A YANG Data Model for LMAP Measurement Agents</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>V. Bajpai</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>LMAP</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a data model for Large-Scale Measurement Platforms (LMAPs).  The data model is defined using the YANG data modeling language.</p></abstract>
        <draft>draft-ietf-lmap-yang-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lmap</wg_acronym>
        <doi>10.17487/RFC8194</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8195</doc-id>
        <title>Use of BGP Large Communities</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>J. Heasley</name>
        </author>
        <author>
            <name>M. Schmidt</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>large</kw>
            <kw>BGP</kw>
            <kw>communities</kw>
        </keywords>
        <abstract><p>This document presents examples and inspiration for operator application of BGP Large Communities.  Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy.  Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire.</p></abstract>
        <draft>draft-ietf-grow-large-communities-usage-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC8195</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8196</doc-id>
        <title>IS-IS Autoconfiguration</title>
        <author>
            <name>B. Liu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>M. Abrahamsson</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>isis auto-configuration</kw>
        </keywords>
        <abstract><p>This document specifies IS-IS autoconfiguration mechanisms.  The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution.  These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected.</p></abstract>
        <draft>draft-ietf-isis-auto-conf-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC8196</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8197</doc-id>
        <title>A SIP Response Code for Unwanted Calls</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>robocall</kw>
            <kw>unwanted</kw>
            <kw>response code</kw>
        </keywords>
        <abstract><p>This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted.  SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.</p></abstract>
        <draft>draft-ietf-sipcore-status-unwanted-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8197</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8198</doc-id>
        <title>Aggressive Use of DNSSEC-Validated Cache</title>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Negative cache</kw>
            <kw>NCACHE</kw>
            <kw>NSEC</kw>
            <kw>NSEC3</kw>
        </keywords>
        <abstract><p>The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.</p><p> This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.</p></abstract>
        <draft>draft-ietf-dnsop-nsec-aggressiveuse-10</draft>
        <updates>
            <doc-id>RFC4035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9077</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8198</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8199</doc-id>
        <title>YANG Module Classification</title>
        <author>
            <name>D. Bogdanovic</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>C. Moberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>service</kw>
            <kw>element</kw>
            <kw>standard</kw>
            <kw>vendor</kw>
            <kw>user</kw>
            <kw>controller</kw>
            <kw>orchestrator</kw>
        </keywords>
        <abstract><p>The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.</p><p> A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.</p><p> This document describes a set of concepts and associated terms to support consistent classification of YANG modules.</p></abstract>
        <draft>draft-ietf-netmod-yang-model-classification-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8199</errata-url>
        <doi>10.17487/RFC8199</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8200</doc-id>
        <title>Internet Protocol, Version 6 (IPv6) Specification</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>next</kw>
            <kw>generation</kw>
            <kw>ipng</kw>
            <kw>flow label</kw>
        </keywords>
        <abstract><p>This document specifies version 6 of the Internet Protocol (IPv6).  It obsoletes RFC 2460.</p></abstract>
        <draft>draft-ietf-6man-rfc2460bis-13</draft>
        <obsoletes>
            <doc-id>RFC2460</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9673</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0086</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8200</errata-url>
        <doi>10.17487/RFC8200</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8201</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>
        <author>
            <name>R. Hinden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MTU-IPv6</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IPv6</kw>
            <kw>link MTU</kw>
            <kw>path MTU</kw>
            <kw>PMTU</kw>
            <kw>Path MTU Discovery</kw>
        </keywords>
        <abstract><p>This document describes Path MTU Discovery (PMTUD) for IP version 6.  It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4.  It obsoletes RFC 1981.</p></abstract>
        <draft>draft-ietf-6man-rfc1981bis-08</draft>
        <obsoletes>
            <doc-id>RFC1981</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0087</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8201</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8202</doc-id>
        <title>IS-IS Multi-Instance</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>June</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.</p><p> Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.</p><p> This document obsoletes RFC 6822.</p></abstract>
        <draft>draft-ietf-isis-mi-bis-03</draft>
        <obsoletes>
            <doc-id>RFC6822</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <doi>10.17487/RFC8202</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8203</doc-id>
        <title>BGP Administrative Shutdown Communication</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>J. Heitz</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>cease</kw>
            <kw>shutdown</kw>
        </keywords>
        <abstract><p>This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset.  This document updates RFC 4486.</p></abstract>
        <draft>draft-ietf-idr-shutdown-10</draft>
        <obsoleted-by>
            <doc-id>RFC9003</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4486</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8204</doc-id>
        <title>Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV)</title>
        <author>
            <name>M. Tahhan</name>
        </author>
        <author>
            <name>B. O'Mahony</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This memo describes the contributions of the Open Platform for NFV (OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test.  This project has extended the current and completed work of the Benchmarking Methodology Working Group in the IETF and references existing literature.  The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions.  Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware.  The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure.</p></abstract>
        <draft>draft-ietf-bmwg-vswitch-opnfv-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8205</doc-id>
        <title>BGPsec Protocol Specification</title>
        <author>
            <name>M. Lepinski</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Sriram</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>BGPsec</kw>
            <kw>BGP AS-path protection</kw>
            <kw>BGP Security</kw>
        </keywords>
        <abstract><p>This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes.  BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message.  The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.</p></abstract>
        <draft>draft-ietf-sidr-bgpsec-protocol-23</draft>
        <updated-by>
            <doc-id>RFC8206</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8206</doc-id>
        <title>BGPsec Considerations for Autonomous System (AS) Migration</title>
        <author>
            <name>W. George</name>
        </author>
        <author>
            <name>S. Murphy</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>as-migration</kw>
            <kw>SIDR</kw>
            <kw>BGPsec</kw>
            <kw>AS_PATH</kw>
        </keywords>
        <abstract><p>This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.</p></abstract>
        <draft>draft-ietf-sidr-as-migration-06</draft>
        <updates>
            <doc-id>RFC8205</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8206</errata-url>
        <doi>10.17487/RFC8206</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8207</doc-id>
        <title>BGPsec Operational Considerations</title>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>RPKI</kw>
            <kw>Routing</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>Deployment of the BGPsec architecture and protocols has many operational considerations.  This document attempts to collect and present the most critical and universal.  Operational practices are expected to evolve as BGPsec is formalized and initially deployed.</p></abstract>
        <draft>draft-ietf-sidr-bgpsec-ops-16</draft>
        <is-also>
            <doc-id>BCP0211</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8208</doc-id>
        <title>BGPsec Algorithms, Key Formats, and Signature Formats</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>O. Borchert</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").</p><p> This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.</p></abstract>
        <draft>draft-ietf-sidr-bgpsec-algs-18</draft>
        <obsoleted-by>
            <doc-id>RFC8608</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC7935</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8209</doc-id>
        <title>A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests</title>
        <author>
            <name>M. Reynolds</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec.  BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together.  BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP.  The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives.  The end entity (EE) certificates specified by this profile are issued to routers within an AS.  Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate.  These CA certificates and EE certificates both contain the AS Resource extension.  An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate.  This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates.  This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487).</p></abstract>
        <draft>draft-ietf-sidr-bgpsec-pki-profiles-21</draft>
        <updates>
            <doc-id>RFC6487</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8209</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8210</doc-id>
        <title>The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.</p><p> This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.</p></abstract>
        <draft>draft-ietf-sidr-rpki-rtr-rfc6810-bis-09</draft>
        <updates>
            <doc-id>RFC6810</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8210</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8211</doc-id>
        <title>Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>D. Ma</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>BGP Security</kw>
        </keywords>
        <abstract><p>This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs.  The analysis is done from the perspective of an affected INR holder.  The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs).  The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.</p></abstract>
        <draft>draft-ietf-sidr-adverse-actions-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <doi>10.17487/RFC8211</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8212</doc-id>
        <title>Default External BGP (EBGP) Route Propagation Behavior without Policies</title>
        <author>
            <name>J. Mauch</name>
        </author>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>G. Hankins</name>
        </author>
        <date>
            <month>July</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>reject</kw>
            <kw>BGP</kw>
            <kw>EBGP</kw>
        </keywords>
        <abstract><p>This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session.</p></abstract>
        <draft>draft-ietf-grow-bgp-reject-08</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC8212</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8213</doc-id>
        <title>Security of Messages Exchanged between Servers and Relay Agents</title>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>Y. Pal</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents.  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption.  With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.</p></abstract>
        <draft>draft-ietf-dhc-relay-server-security-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8214</doc-id>
        <title>Virtual Private Wire Service Support in Ethernet VPN</title>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks.  EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.</p></abstract>
        <draft>draft-ietf-bess-evpn-vpws-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8214</errata-url>
        <doi>10.17487/RFC8214</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8215</doc-id>
        <title>Local-Use IPv4/IPv6 Translation Prefix</title>
        <author>
            <name>T. Anderson</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6 transition</kw>
            <kw>IVI</kw>
            <kw>MAP</kw>
            <kw>NAT64</kw>
            <kw>SIIT</kw>
            <kw>SIIT-DC</kw>
            <kw>Transition</kw>
        </keywords>
        <abstract><p>This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.</p></abstract>
        <draft>draft-ietf-v6ops-v4v6-xlat-prefix-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8215</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8216</doc-id>
        <title>HTTP Live Streaming</title>
        <author>
            <name>R. Pantos</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. May</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>HTML</kw>
            <kw>streaming</kw>
            <kw>media</kw>
        </keywords>
        <abstract><p>This document describes a protocol for transferring unbounded streams of multimedia data.  It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams.  It describes version 7 of this protocol.</p></abstract>
        <draft>draft-pantos-http-live-streaming-23</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8216</errata-url>
        <doi>10.17487/RFC8216</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8217</doc-id>
        <title>Clarifications for When to Use the name-addr Production in SIP Messages</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.</p><p> This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502).</p></abstract>
        <draft>draft-ietf-sipcore-name-addr-guidance-02</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3325</doc-id>
            <doc-id>RFC3515</doc-id>
            <doc-id>RFC3892</doc-id>
            <doc-id>RFC4508</doc-id>
            <doc-id>RFC5002</doc-id>
            <doc-id>RFC5318</doc-id>
            <doc-id>RFC5360</doc-id>
            <doc-id>RFC5502</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8217</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8218</doc-id>
        <title>Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)</title>
        <author>
            <name>J. Yi</name>
        </author>
        <author>
            <name>B. Parrein</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>MANET</kw>
        </keywords>
        <abstract><p>This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs).  Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures.  The interoperability with OLSRv2 is retained.</p></abstract>
        <draft>draft-ietf-manet-olsrv2-multipath-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8218</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8219</doc-id>
        <title>Benchmarking Methodology for IPv6 Transition Technologies</title>
        <author>
            <name>M. Georgescu</name>
        </author>
        <author>
            <name>L. Pislaru</name>
        </author>
        <author>
            <name>G. Lencse</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Single Translation Technologies</kw>
            <kw>Double Translation Technologies</kw>
            <kw>Encapsulation Technologies</kw>
            <kw>NAT64</kw>
            <kw>DNS64</kw>
            <kw>MAP-E</kw>
            <kw>MAP-T</kw>
            <kw>DSLite</kw>
            <kw>464XLAT</kw>
            <kw>6PE</kw>
            <kw>DNS Resolution Performance</kw>
            <kw>Overload Scalability</kw>
            <kw>Typical Latency</kw>
            <kw>Worst Case Latency</kw>
            <kw>PDV</kw>
            <kw>IPDV</kw>
        </keywords>
        <abstract><p>Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope.  This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies.  More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180.  The methodology also includes a metric for benchmarking load scalability.</p></abstract>
        <draft>draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8219</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8220</doc-id>
        <title>Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)</title>
        <author>
            <name>O. Dornon</name>
        </author>
        <author>
            <name>J. Kotalwar</name>
        </author>
        <author>
            <name>V. Hemige</name>
        </author>
        <author>
            <name>R. Qiu</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.</p><p> With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.</p><p> This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.</p></abstract>
        <draft>draft-ietf-pals-vpls-pim-snooping-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8220</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8221</doc-id>
        <title>Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>J. Mattsson</name>
        </author>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>IKE</kw>
        </keywords>
        <abstract><p>This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)".  The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.</p></abstract>
        <draft>draft-ietf-ipsecme-rfc7321bis-06</draft>
        <obsoletes>
            <doc-id>RFC7321</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9395</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8221</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8222</doc-id>
        <title>Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery</title>
        <author>
            <name>A. Sullivan</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>mDNS</kw>
            <kw>DNS-SD</kw>
        </keywords>
        <abstract><p>Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services.  Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets.  This is of particular relevance where some environments use DNS labels that conform to Internationalized Domain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8).  In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment.  This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.</p></abstract>
        <draft>draft-ietf-dnssd-mdns-dns-interop-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC8222</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8223</doc-id>
        <title>Application-Aware Targeted LDP</title>
        <author>
            <name>S. Esale</name>
        </author>
        <author>
            <name>R. Torvi</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <author>
            <name>U. Chunduri</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with any Label Switching Router (LSR) in a network.  The initiating LSR has information about the targeted applications to administratively control initiation of the session.  However, the responding LSR has no such information to control acceptance of this session.  This document defines a mechanism to advertise and negotiate the Targeted Application Capability (TAC) during LDP session initialization.  As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications.  In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session.  This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.</p></abstract>
        <draft>draft-ietf-mpls-app-aware-tldp-09</draft>
        <updates>
            <doc-id>RFC7473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8223</errata-url>
        <doi>10.17487/RFC8223</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8224</doc-id>
        <title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>C. Wendt</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Secure Origin Identification</kw>
            <kw>Communication Security</kw>
            <kw>RTCWeb</kw>
            <kw>Certificates</kw>
            <kw>Real-Time Communication</kw>
        </keywords>
        <abstract><p>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</p><p> This document obsoletes RFC 4474.</p></abstract>
        <draft>draft-ietf-stir-rfc4474bis-16</draft>
        <obsoletes>
            <doc-id>RFC4474</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8946</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8224</errata-url>
        <doi>10.17487/RFC8224</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8225</doc-id>
        <title>PASSporT: Personal Assertion Token</title>
        <author>
            <name>C. Wendt</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications.  The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination.  The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel.  PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.</p></abstract>
        <draft>draft-ietf-stir-passport-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8225</errata-url>
        <doi>10.17487/RFC8225</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8226</doc-id>
        <title>Secure Telephone Identity Credentials: Certificates</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>TNAuthorizationList</kw>
            <kw>JWTClaimConstraints</kw>
        </keywords>
        <abstract><p>In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers.  This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.</p></abstract>
        <draft>draft-ietf-stir-certificates-17</draft>
        <updated-by>
            <doc-id>RFC9118</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8226</errata-url>
        <doi>10.17487/RFC8226</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8227</doc-id>
        <title>MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology</title>
        <author>
            <name>W. Cheng</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>wrapping protection</kw>
            <kw>short-wrapping protection</kw>
            <kw>steering protection</kw>
            <kw>ring protection</kw>
            <kw>shared ring protection</kw>
            <kw>protection switching</kw>
        </keywords>
        <abstract><p>This document describes requirements, architecture, and solutions for MPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services.  The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654.  This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring.</p></abstract>
        <draft>draft-ietf-mpls-tp-shared-ring-protection-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8228</doc-id>
        <title>Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels</title>
        <author>
            <name>A. Freytag</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>LGR</kw>
            <kw>Variant</kw>
            <kw>IDN</kw>
        </keywords>
        <abstract><p>Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs).  This document describes ways to design LGRs to support variant labels.  In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants.  The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940.</p></abstract>
        <draft>draft-freytag-lager-variant-rules-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8228</errata-url>
        <doi>10.17487/RFC8228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8229</doc-id>
        <title>TCP Encapsulation of IKE and IPsec Packets</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>S. Touati</name>
        </author>
        <author>
            <name>R. Mantha</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IKEv2</kw>
            <kw>IPsec</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP.  This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection.  This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.</p></abstract>
        <draft>draft-ietf-ipsecme-tcp-encaps-10</draft>
        <obsoleted-by>
            <doc-id>RFC9329</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8229</errata-url>
        <doi>10.17487/RFC8229</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8230</doc-id>
        <title>Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages</title>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Cryptography</kw>
            <kw>Digital Signature</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract><p>The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR).  This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages.  Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys.</p></abstract>
        <draft>draft-jones-cose-rsa-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8230</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8231</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
        <author>
            <name>E. Crabbe</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>J. Medved</name>
        </author>
        <author>
            <name>R. Varga</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>Stateful PCE</kw>
        </keywords>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</p><p> Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-21</draft>
        <updated-by>
            <doc-id>RFC8786</doc-id>
            <doc-id>RFC9353</doc-id>
            <doc-id>RFC9753</doc-id>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8231</errata-url>
        <doi>10.17487/RFC8231</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8232</doc-id>
        <title>Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE</title>
        <author>
            <name>E. Crabbe</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>J. Medved</name>
        </author>
        <author>
            <name>R. Varga</name>
        </author>
        <author>
            <name>X. Zhang</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Stateful PCE</kw>
            <kw>state synchronization</kw>
            <kw>optimization</kw>
        </keywords>
        <abstract><p>A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation.  The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions.  This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs.  The basic mechanism for State Synchronization is part of the stateful PCE specification.  This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.</p></abstract>
        <draft>draft-ietf-pce-stateful-sync-optimizations-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8232</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8233</doc-id>
        <title>Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>K. Kumaki</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>PCEP</kw>
            <kw>service-aware</kw>
            <kw>metric</kw>
            <kw>BU</kw>
            <kw>LBU</kw>
            <kw>LRBU</kw>
        </keywords>
        <abstract><p>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.</p><p> IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.</p></abstract>
        <draft>draft-ietf-pce-pcep-service-aware-13</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8233</errata-url>
        <doi>10.17487/RFC8233</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8234</doc-id>
        <title>Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode</title>
        <author>
            <name>J. Ryoo</name>
        </author>
        <author>
            <name>T. Cheung</name>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>I. Busi</name>
        </author>
        <author>
            <name>G. Wen</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>APS mode</kw>
            <kw>initialization</kw>
            <kw>mpls-tp linear protection</kw>
        </keywords>
        <abstract><p>This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271.  The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.</p></abstract>
        <draft>draft-ietf-mpls-tp-aps-updates-04</draft>
        <updates>
            <doc-id>RFC7271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8235</doc-id>
        <title>Schnorr Non-interactive Zero-Knowledge Proof</title>
        <author>
            <name>F. Hao</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Zero-Knowledge Proof</kw>
            <kw>Schnorr NIZK proof</kw>
            <kw>Identification protocol</kw>
        </keywords>
        <abstract><p>This document describes the Schnorr non-interactive zero-knowledge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme.  The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value.  It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly.  This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.</p></abstract>
        <draft>draft-hao-schnorr-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8235</errata-url>
        <doi>10.17487/RFC8235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8236</doc-id>
        <title>J-PAKE: Password-Authenticated Key Exchange by Juggling</title>
        <author>
            <name>F. Hao</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol.  This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.</p></abstract>
        <draft>draft-hao-jpake-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8236</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8237</doc-id>
        <title>MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs</title>
        <author>
            <name>L. Martini</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>E. Bellagamba</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP.</p><p> The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.</p></abstract>
        <draft>draft-ietf-pals-status-reduction-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8237</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8238</doc-id>
        <title>Data Center Benchmarking Terminology</title>
        <author>
            <name>L. Avramov</name>
        </author>
        <author>
            <name>J. Rapp</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment.  This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239).  Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.</p></abstract>
        <draft>draft-ietf-bmwg-dcbench-terminology-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8238</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8239</doc-id>
        <title>Data Center Benchmarking Methodology</title>
        <author>
            <name>L. Avramov</name>
        </author>
        <author>
            <name>J. Rapp</name>
        </author>
        <date>
            <month>August</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center.  RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative.  Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.</p></abstract>
        <draft>draft-ietf-bmwg-dcbench-methodology-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8239</errata-url>
        <doi>10.17487/RFC8239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8240</doc-id>
        <title>Report from the Internet of Things Software Update (IoTSU) Workshop 2016</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Firmware Updates</kw>
            <kw>Software Updates</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-iotsu-workshop-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8240</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8241</doc-id>
        <title>Interface to the Routing System (I2RS) Security-Related Requirements</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921).  The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them.  One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection.  The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport.</p></abstract>
        <draft>draft-ietf-i2rs-protocol-security-requirements-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC8241</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8242</doc-id>
        <title>Interface to the Routing System (I2RS) Ephemeral State Requirements</title>
        <author>
            <name>J. Haas</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System (I2RS) protocol has to provide.  This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol.</p></abstract>
        <draft>draft-ietf-i2rs-ephemeral-state-23</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC8242</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8243</doc-id>
        <title>Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>H. Zhai</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>aggregaged nickname</kw>
            <kw>unique nickname</kw>
        </keywords>
        <abstract><p>Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?</p><p> This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.</p></abstract>
        <draft>draft-ietf-trill-rbridge-multilevel-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8243</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8244</doc-id>
        <title>Special-Use Domain Names Problem Statement</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SUN</kw>
            <kw>SUTLD</kw>
            <kw>RFC6761</kw>
        </keywords>
        <abstract><p>The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.</p><p> This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.</p></abstract>
        <draft>draft-ietf-dnsop-sutld-ps-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8245</doc-id>
        <title>Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444</title>
        <author>
            <name>T. Clausen</name>
        </author>
        <author>
            <name>C. Dearlove</name>
        </author>
        <author>
            <name>U. Herberg</name>
        </author>
        <author>
            <name>H. Rogge</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>MANET</kw>
        </keywords>
        <abstract><p>RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexed MANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies.  This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format.  In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.</p></abstract>
        <draft>draft-ietf-manet-rfc5444-usage-07</draft>
        <updates>
            <doc-id>RFC5444</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8246</doc-id>
        <title>HTTP Immutable Responses</title>
        <author>
            <name>P. McManus</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime.  This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.</p></abstract>
        <draft>draft-ietf-httpbis-immutable-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8247</doc-id>
        <title>Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IPsec</kw>
            <kw>IKE</kw>
            <kw>internet key exchange</kw>
        </keywords>
        <abstract><p>The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services.  The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used.  To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support.  This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry.  This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).</p></abstract>
        <draft>draft-ietf-ipsecme-rfc4307bis-18</draft>
        <obsoletes>
            <doc-id>RFC4307</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC7296</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9395</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8247</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8248</doc-id>
        <title>Security Automation and Continuous Monitoring (SACM) Requirements</title>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>L. Lorenzin</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>posture assessment</kw>
            <kw>posture validation</kw>
            <kw>software integrity</kw>
            <kw>network authorization</kw>
            <kw>software compliance</kw>
        </keywords>
        <abstract><p>This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols.  The requirements and scope are based on the agreed-upon use cases described in RFC 7632.</p></abstract>
        <draft>draft-ietf-sacm-requirements-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacm</wg_acronym>
        <doi>10.17487/RFC8248</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8249</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation</title>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>X. Zhang</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>S. Chatterjee</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets.  This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU.  In addition, it specifies an efficient algorithm for local MTU testing.  This document updates RFCs 6325, 7177, and 7780.</p></abstract>
        <draft>draft-ietf-trill-mtu-negotiation-08</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
            <doc-id>RFC7177</doc-id>
            <doc-id>RFC7780</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8249</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8250</doc-id>
        <title>IPv6 Performance and Diagnostic Metrics (PDM) Destination Option</title>
        <author>
            <name>N. Elkins</name>
        </author>
        <author>
            <name>R. Hamilton</name>
        </author>
        <author>
            <name>M. Ackermann</name>
        </author>
        <date>
            <month>September</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements.  Such measurements may be interpreted in real time or after the fact.  This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header.  The field limits, calculations, and usage in measurement of PDM are included in this document.</p></abstract>
        <draft>draft-ietf-ippm-6man-pdm-option-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8250</errata-url>
        <doi>10.17487/RFC8250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8251</doc-id>
        <title>Updates to the Opus Audio Codec</title>
        <author>
            <name>JM. Valin</name>
        </author>
        <author>
            <name>K. Vos</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716.  It updates the normative decoder implementation included in Appendix A of RFC 6716.  The changes fix real and potential security-related issues, as well as minor quality-related issues.</p></abstract>
        <draft>draft-ietf-codec-opus-update-10</draft>
        <updates>
            <doc-id>RFC6716</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>codec</wg_acronym>
        <doi>10.17487/RFC8251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8252</doc-id>
        <title>OAuth 2.0 for Native Apps</title>
        <author>
            <name>W. Denniss</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser.  This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.</p></abstract>
        <draft>draft-ietf-oauth-native-apps-12</draft>
        <updates>
            <doc-id>RFC6749</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0212</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8252</errata-url>
        <doi>10.17487/RFC8252</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8253</doc-id>
        <title>PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>PCEP</kw>
            <kw>PCEPS</kw>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>encryption</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.</p><p> This document updates RFC 5440 in regards to the PCEP initialization phase procedures.</p></abstract>
        <draft>draft-ietf-pce-pceps-18</draft>
        <updates>
            <doc-id>RFC5440</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8253</errata-url>
        <doi>10.17487/RFC8253</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8254</doc-id>
        <title>Uniform Resource Name (URN) Namespace Registration Transition</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>J. Hakala</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ISBN</kw>
            <kw>ISSN</kw>
            <kw>NBN</kw>
            <kw>national bibliography number</kw>
        </keywords>
        <abstract><p>The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus.  That requirement discouraged some registrations and increased the risk for problems that could occur as a result.  The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces.  This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations.  This document also obsoletes RFCs 3044 and 3187 and moves them to Historic status.  These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates.</p></abstract>
        <draft>draft-ietf-urnbis-ns-reg-transition-08</draft>
        <obsoletes>
            <doc-id>RFC3044</doc-id>
            <doc-id>RFC3187</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>urnbis</wg_acronym>
        <doi>10.17487/RFC8254</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8255</doc-id>
        <title>Multiple Language Content Type</title>
        <author>
            <name>N. Tomkinson</name>
        </author>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>multiple</kw>
            <kw>language</kw>
            <kw>multi</kw>
            <kw>lingual</kw>
            <kw>content</kw>
            <kw>type</kw>
            <kw>email</kw>
            <kw>mime</kw>
        </keywords>
        <abstract><p>This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard.  This content type makes it possible to send one message that contains multiple language versions of the same information.  The translations would be identified by a language tag and selected by the email client based on a user's language settings.</p></abstract>
        <draft>draft-ietf-slim-multilangcontent-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>slim</wg_acronym>
        <doi>10.17487/RFC8255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8256</doc-id>
        <title>Requirements for Hitless MPLS Path Segment Monitoring</title>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>S. Ueno</name>
        </author>
        <author>
            <name>K. Arai</name>
        </author>
        <author>
            <name>Y. Koike</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>HPSM</kw>
            <kw>MPLS</kw>
            <kw>MPLS Transport Profile</kw>
            <kw>mpls-tp</kw>
            <kw>OAM</kw>
            <kw>monitoring</kw>
            <kw>Hitless Path Segment Monitoring</kw>
            <kw>Path Segment Monitoring</kw>
            <kw>HPSM</kw>
        </keywords>
        <abstract><p>One of the most important Operations, Administration, and Maintenance (OAM) capabilities for transport-network operation is fault localization.  An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints.  However, the current segment monitoring approach defined for MPLS (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" has drawbacks.  This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support Hitless Path Segment Monitoring (HPSM).</p></abstract>
        <draft>draft-ietf-mpls-tp-temporal-hitless-psm-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8256</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8257</doc-id>
        <title>Data Center TCP (DCTCP): TCP Congestion Control for Data Centers</title>
        <author>
            <name>S. Bensley</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>P. Balasubramanian</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>G. Judd</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>ECN</kw>
            <kw>DCTCP</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic.  DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred.  DCTCP then scales the TCP congestion window based on this estimate.  This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches.  This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations.  This memo documents DCTCP as currently implemented by several major operating systems.  DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures.</p></abstract>
        <draft>draft-ietf-tcpm-dctcp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8257</errata-url>
        <doi>10.17487/RFC8257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8258</doc-id>
        <title>Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)</title>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>OSPF-TE</kw>
            <kw>GMPLS</kw>
        </keywords>
        <abstract><p>This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields.  This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs and any specific technology.  This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types.  The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards.</p></abstract>
        <draft>draft-ietf-teas-gmpls-scsi-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8258</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8259</doc-id>
        <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
        <author>
            <name>T. Bray</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</p><p> This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</p></abstract>
        <draft>draft-ietf-jsonbis-rfc7159bis-04</draft>
        <obsoletes>
            <doc-id>RFC7159</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0090</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jsonbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8259</errata-url>
        <doi>10.17487/RFC8259</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8260</doc-id>
        <title>Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>R. Seggelmann</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.</p><p> Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-ndata-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8260</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8261</doc-id>
        <title>Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>R. Jesup</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6.  This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol.  Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks.  As a consequence, the SCTP associations carried over DTLS can only be single-homed.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-dtls-encaps-09</draft>
        <updated-by>
            <doc-id>RFC8899</doc-id>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8261</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8262</doc-id>
        <title>Content-ID Header Field in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>I. Sedlacek</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.</p><p> This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.</p></abstract>
        <draft>draft-ietf-sipcore-content-id-10</draft>
        <updates>
            <doc-id>RFC5621</doc-id>
            <doc-id>RFC5368</doc-id>
            <doc-id>RFC6442</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8262</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8263</doc-id>
        <title>Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message</title>
        <author>
            <name>B. Weis</name>
        </author>
        <author>
            <name>U. Mangla</name>
        </author>
        <author>
            <name>T. Karl</name>
        </author>
        <author>
            <name>N. Maheshwari</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>multicast security</kw>
        </keywords>
        <abstract><p>The Group Domain of Interpretation (GDOI) includes the ability of a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations).  This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.</p></abstract>
        <draft>draft-weis-gdoi-rekey-ack-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8263</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8264</doc-id>
        <title>PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>internationalization</kw>
            <kw>i18n</kw>
            <kw>Stringprep</kw>
        </keywords>
        <abstract><p>Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization).  This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode.  As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  This document obsoletes RFC 7564.</p></abstract>
        <draft>draft-ietf-precis-7564bis-10</draft>
        <obsoletes>
            <doc-id>RFC7564</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>precis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8264</errata-url>
        <doi>10.17487/RFC8264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8265</doc-id>
        <title>Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Username</kw>
            <kw>Password</kw>
            <kw>Unicode</kw>
            <kw>Internationalization</kw>
            <kw>i18n</kw>
            <kw>Authentication</kw>
            <kw>SASLprep</kw>
        </keywords>
        <abstract><p>This document describes updated methods for handling Unicode strings representing usernames and passwords.  The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).  The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords.  This document obsoletes RFC 7613.</p></abstract>
        <draft>draft-ietf-precis-7613bis-11</draft>
        <obsoletes>
            <doc-id>RFC7613</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>precis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8265</errata-url>
        <doi>10.17487/RFC8265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8266</doc-id>
        <title>Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>nickname</kw>
            <kw>SIP</kw>
            <kw>SIMPLE</kw>
            <kw>XMPP</kw>
            <kw>MSRP</kw>
            <kw>XCON</kw>
            <kw>chatrooms</kw>
        </keywords>
        <abstract><p>This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities.  This document obsoletes RFC 7700.</p></abstract>
        <draft>draft-ietf-precis-7700bis-10</draft>
        <obsoletes>
            <doc-id>RFC7700</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>precis</wg_acronym>
        <doi>10.17487/RFC8266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8267</doc-id>
        <title>Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1</title>
        <author>
            <name>C. Lever</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>NFS-over-RDMA</kw>
        </keywords>
        <abstract><p>This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement.  This document obsoletes RFC 5667.</p></abstract>
        <draft>draft-ietf-nfsv4-rfc5667bis-13</draft>
        <obsoletes>
            <doc-id>RFC5667</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8268</doc-id>
        <title>More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)</title>
        <author>
            <name>M. Baushke</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Public Key</kw>
            <kw>Private Key</kw>
            <kw>group14</kw>
            <kw>group15</kw>
            <kw>group16</kw>
            <kw>group17</kw>
            <kw>groupt18</kw>
            <kw>2048-bit</kw>
            <kw>3072-bit</kw>
            <kw>4096-bit</kw>
            <kw>6144-bit</kw>
            <kw>8192-bit</kw>
        </keywords>
        <abstract><p>This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes.  This document updates RFC 4250.  This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.</p></abstract>
        <draft>draft-ietf-curdle-ssh-modp-dh-sha2-09</draft>
        <updates>
            <doc-id>RFC4250</doc-id>
            <doc-id>RFC4253</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8268</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8269</doc-id>
        <title>The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)</title>
        <author>
            <name>W. Kim</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>J. Park</name>
        </author>
        <author>
            <name>D. Kwon</name>
        </author>
        <author>
            <name>D. Kim</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ARIA</kw>
            <kw>SRTP</kw>
            <kw>DTLS-SRTP</kw>
            <kw>MIKEY</kw>
        </keywords>
        <abstract><p>This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP).  It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA.  Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA.</p></abstract>
        <draft>draft-ietf-avtcore-aria-srtp-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8270</doc-id>
        <title>Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits</title>
        <author>
            <name>L. Velvindron</name>
        </author>
        <author>
            <name>M. Baushke</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>SSH</kw>
            <kw>DH</kw>
        </keywords>
        <abstract><p>The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits.  Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources.  This RFC updates RFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size.</p></abstract>
        <draft>draft-ietf-curdle-ssh-dh-group-exchange-06</draft>
        <updates>
            <doc-id>RFC4419</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8270</errata-url>
        <doi>10.17487/RFC8270</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8271</doc-id>
        <title>Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>M. Taillon</name>
        </author>
        <author>
            <name>T. Saad</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>M. Bhatia</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Co-routed LSPs</kw>
            <kw>Bypass assignment coordinate</kw>
            <kw>Restore co-routing</kw>
        </keywords>
        <abstract><p>This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs).  These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP.  In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.</p></abstract>
        <draft>draft-ietf-teas-gmpls-lsp-fastreroute-12</draft>
        <updates>
            <doc-id>RFC4090</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8271</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8272</doc-id>
        <title>TinyIPFIX for Smart Meters in Constrained Networks</title>
        <author>
            <name>C. Schmitt</name>
        </author>
        <author>
            <name>B. Stiller</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>TinyIPFIX</kw>
            <kw>Smart Meters</kw>
            <kw>Constrained Networks</kw>
        </keywords>
        <abstract><p>This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944).  TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks.  This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device.</p></abstract>
        <draft>draft-schmitt-ipfix-tiny-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8272</errata-url>
        <doi>10.17487/RFC8272</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8273</doc-id>
        <title>Unique IPv6 Prefix per Host</title>
        <author>
            <name>J. Brzozowski</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix).  Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.</p></abstract>
        <draft>draft-ietf-v6ops-unique-ipv6-prefix-per-host-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8273</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8274</doc-id>
        <title>Incident Object Description Exchange Format Usage Guidance</title>
        <author>
            <name>P. Kampanakis</name>
        </author>
        <author>
            <name>M. Suzuki</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IODEF best practices</kw>
            <kw>IODEF implementation recommendations</kw>
            <kw>IODEF examples</kw>
            <kw>IODEF practical recommendations</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged by Computer Security Incident Response Teams (CSIRTs) .  Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing.  This document provides guidelines for IODEF implementers.  It addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being used.  This document aims to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by CSIRTs around the world.</p></abstract>
        <draft>draft-ietf-mile-iodef-guidance-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC8274</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8275</doc-id>
        <title>Allowing Inheritable NFSv4 Access Control Entries to Override the Umask</title>
        <author>
            <name>J. Fields</name>
        </author>
        <author>
            <name>A. Gruenbacher</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask).  This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files.  This document proposes a protocol extension to accomplish that.</p></abstract>
        <draft>draft-ietf-nfsv4-umask-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8275</errata-url>
        <doi>10.17487/RFC8275</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8276</doc-id>
        <title>File System Extended Attributes in NFSv4</title>
        <author>
            <name>M. Naik</name>
        </author>
        <author>
            <name>M. Eshel</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document describes an optional feature extending the NFSv4 protocol.  This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients.  Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories.  Such support is present in many modern local file systems.  New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.</p></abstract>
        <draft>draft-ietf-nfsv4-xattrs-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8276</errata-url>
        <doi>10.17487/RFC8276</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8277</doc-id>
        <title>Using BGP to Bind MPLS Labels to Address Prefixes</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>AAL</kw>
            <kw>syntax</kw>
            <kw>adaption</kw>
            <kw>layer</kw>
        </keywords>
        <abstract><p>This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix.  This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s).  This document obsoletes RFC 3107.</p></abstract>
        <draft>draft-ietf-mpls-rfc3107bis-04</draft>
        <obsoletes>
            <doc-id>RFC3107</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8277</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8278</doc-id>
        <title>Mobile Access Gateway (MAG) Multipath Options</title>
        <author>
            <name>P. Seite</name>
        </author>
        <author>
            <name>A. Yegin</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Proxy Mobile IPv6 (PMIPv6)</kw>
            <kw>multihoming</kw>
            <kw>Multiple WAN accesses</kw>
        </keywords>
        <abstract><p>This specification defines extensions to the Proxy Mobile IPv6 (PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA.  This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic.  This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option.</p></abstract>
        <draft>draft-ietf-dmm-mag-multihoming-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8278</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8279</doc-id>
        <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Dolganow</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>This document specifies a new architecture for the forwarding of multicast data packets.  It provides optimal forwarding of multicast packets through a "multicast domain".  However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state.  This architecture is known as "Bit Index Explicit Replication" (BIER).  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The procedures for forwarding a packet based on its BIER header are specified in this document.  Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</p></abstract>
        <draft>draft-ietf-bier-architecture-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <doi>10.17487/RFC8279</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8280</doc-id>
        <title>Research into Human Rights Protocol Considerations</title>
        <author>
            <name>N. ten Oever</name>
        </author>
        <author>
            <name>C. Cath</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>81</page-count>
        <keywords>
            <kw>human rights</kw>
            <kw>IETF</kw>
            <kw>protocols</kw>
            <kw>guidelines</kw>
            <kw>considerations</kw>
            <kw>freedom of expression</kw>
        </keywords>
        <abstract><p>This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.</p><p> This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.</p></abstract>
        <draft>draft-irtf-hrpc-research-14</draft>
        <updated-by>
            <doc-id>RFC9620</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8280</errata-url>
        <doi>10.17487/RFC8280</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8281</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
        <author>
            <name>E. Crabbe</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>R. Varga</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</p><p> The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</p></abstract>
        <draft>draft-ietf-pce-pce-initiated-lsp-11</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8281</errata-url>
        <doi>10.17487/RFC8281</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8282</doc-id>
        <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>E. Oki</name>
        </author>
        <author>
            <name>T. Takeda</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>F. Zhang</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Multi-layer</kw>
            <kw>Multi-domain</kw>
            <kw>Inter-domain</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</p><p> MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.</p><p> The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.</p></abstract>
        <draft>draft-ietf-pce-inter-layer-ext-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8282</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8283</doc-id>
        <title>An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Q. Zhao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>SDN</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.</p><p> PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).</p><p> SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.</p><p> This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.</p><p> This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.</p></abstract>
        <draft>draft-ietf-teas-pce-central-control-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8283</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8284</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs).  The Lightweight Directory Access Protocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols.  This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications.</p></abstract>
        <draft>draft-kille-ldap-xmpp-schema-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8284</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8285</doc-id>
        <title>A General Mechanism for RTP Header Extensions</title>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>H. Desineni</name>
        </author>
        <author>
            <name>R. Even</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol).  It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized.  The actual extensions in use in a session are signaled in the setup information for that session.  This document obsoletes RFC 5285.</p></abstract>
        <draft>draft-ietf-avtcore-rfc5285-bis-14</draft>
        <obsoletes>
            <doc-id>RFC5285</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8285</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8286</doc-id>
        <title>RTP/RTCP Extension for RTP Splicing Notification</title>
        <author>
            <name>J. Xia</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <author>
            <name>L. Deng</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.</p><p> This memo defines two RTP/RTCP extensions to indicate the splicing-related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band.</p></abstract>
        <draft>draft-ietf-avtext-splicing-notification-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC8286</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8287</doc-id>
        <title>Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes</title>
        <author>
            <name>N. Kumar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>S. Kini</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LSP Ping</kw>
            <kw>SPRING</kw>
            <kw>Segment Routing</kw>
            <kw>SR</kw>
        </keywords>
        <abstract><p>A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.</p><p> The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.</p></abstract>
        <draft>draft-ietf-mpls-spring-lsp-ping-13</draft>
        <updated-by>
            <doc-id>RFC8690</doc-id>
            <doc-id>RFC9214</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8287</errata-url>
        <doi>10.17487/RFC8287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8288</doc-id>
        <title>Web Linking</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>October</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>link relation</kw>
        </keywords>
        <abstract><p>This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</p><p> It also defines the serialisation of such links in HTTP headers with the Link header field.</p></abstract>
        <draft>draft-nottingham-rfc5988bis-08</draft>
        <obsoletes>
            <doc-id>RFC5988</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8288</errata-url>
        <doi>10.17487/RFC8288</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8289</doc-id>
        <title>Controlled Delay Active Queue Management</title>
        <author>
            <name>K. Nichols</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>A. McGregor</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Iyengar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>CoDel</kw>
            <kw>AQM</kw>
            <kw>Active Queue Management</kw>
        </keywords>
        <abstract><p>This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments.  CoDel consists of an estimator, a setpoint, and a control loop.  It requires no configuration in normal Internet deployments.</p></abstract>
        <draft>draft-ietf-aqm-codel-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <doi>10.17487/RFC8289</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8290</doc-id>
        <title>The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm</title>
        <author>
            <name>T. Hoeiland-Joergensen</name>
        </author>
        <author>
            <name>P. McKenney</name>
        </author>
        <author>
            <name>D. Taht</name>
        </author>
        <author>
            <name>J. Gettys</name>
        </author>
        <author>
            <name>E. Dumazet</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>bufferbloat</kw>
            <kw>aqm</kw>
            <kw>fq_codel</kw>
            <kw>fq-codel</kw>
        </keywords>
        <abstract><p>This memo presents the FQ-CoDel hybrid packet scheduler and Active Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.</p><p> FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware.</p></abstract>
        <draft>draft-ietf-aqm-fq-codel-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>aqm</wg_acronym>
        <doi>10.17487/RFC8290</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8291</doc-id>
        <title>Message Encryption for Web Push</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>web</kw>
            <kw>push</kw>
            <kw>notification</kw>
            <kw>http</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document describes a message encryption scheme for the Web Push protocol.  This scheme provides confidentiality and integrity for messages sent from an application server to a user agent.</p></abstract>
        <draft>draft-ietf-webpush-encryption-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>webpush</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8291</errata-url>
        <doi>10.17487/RFC8291</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8292</doc-id>
        <title>Voluntary Application Server Identification (VAPID) for Web Push</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>P. Beverloo</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>restricted</kw>
            <kw>restriction</kw>
            <kw>signature</kw>
        </keywords>
        <abstract><p>An application server can use the Voluntary Application Server Identification (VAPID) method described in this document to voluntarily identify itself to a push service.  The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes.  The signature can be used by the push service to attribute requests that are made by the same application server to a single entity.  The identification information can allow the operator of a push service to contact the operator of the application server.  The signature can be used to restrict the use of a push message subscription to a single application server.</p></abstract>
        <draft>draft-ietf-webpush-vapid-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>webpush</wg_acronym>
        <doi>10.17487/RFC8292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8293</doc-id>
        <title>A Framework for Multicast in Network Virtualization over Layer 3</title>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>M. McBride</name>
        </author>
        <author>
            <name>V. Bannai</name>
        </author>
        <author>
            <name>R. Krishnan</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NVO3</kw>
            <kw>VXLAN</kw>
            <kw>Geneve</kw>
            <kw>NVGRE</kw>
        </keywords>
        <abstract><p>This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3).  Both infrastructure multicast and application-specific multicast are discussed.  It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms.</p></abstract>
        <draft>draft-ietf-nvo3-mcast-framework-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC8293</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8294</doc-id>
        <title>Common YANG Data Types for the Routing Area</title>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>C. Hopps</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Routing</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a collection of common data types using the YANG data modeling language.  These derived common types are designed to be imported by other modules defined in the routing area.</p></abstract>
        <draft>draft-ietf-rtgwg-routing-types-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8294</errata-url>
        <doi>10.17487/RFC8294</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8295</doc-id>
        <title>EST (Enrollment over Secure Transport) Extensions</title>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>Firmware</kw>
            <kw>TAMP</kw>
            <kw>Asymmetric Keys</kw>
            <kw>Symmetric Keys</kw>
            <kw>Product Availability List</kw>
        </keywords>
        <abstract><p>The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll).  This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys.  This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them.  This document extends the EST server path components to provide these additional services.</p></abstract>
        <draft>draft-turner-est-extensions-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8295</errata-url>
        <doi>10.17487/RFC8295</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8296</doc-id>
        <title>Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks</title>
        <author>
            <name>IJ. Wijnands</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Dolganow</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>I. Meilik</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol.  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The details of the encapsulation depend on the type of network used to realize the multicast domain.  This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.</p></abstract>
        <draft>draft-ietf-bier-mpls-encapsulation-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8296</errata-url>
        <doi>10.17487/RFC8296</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8297</doc-id>
        <title>An HTTP Status Code for Indicating Hints</title>
        <author>
            <name>K. Oku</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>push</kw>
            <kw>preload</kw>
        </keywords>
        <abstract><p>This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.</p></abstract>
        <draft>draft-ietf-httpbis-early-hints-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8298</doc-id>
        <title>Self-Clocked Rate Adaptation for Multimedia</title>
        <author>
            <name>I. Johansson</name>
        </author>
        <author>
            <name>Z. Sarker</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Cellular Network</kw>
            <kw>Congestion Control</kw>
            <kw>RTP</kw>
        </keywords>
        <abstract><p>This memo describes a rate adaptation algorithm for conversational media services such as interactive video.  The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm.  The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.</p></abstract>
        <draft>draft-ietf-rmcat-scream-cc-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8298</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8299</doc-id>
        <title>YANG Data Model for L3VPN Service Delivery</title>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>L. Tomotaki</name>
        </author>
        <author>
            <name>K. Ogaki</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>188</page-count>
        <abstract><p>This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.</p><p> This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.</p></abstract>
        <draft>draft-wu-l3sm-rfc8049bis-11</draft>
        <obsoletes>
            <doc-id>RFC8049</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8299</errata-url>
        <doi>10.17487/RFC8299</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8300</doc-id>
        <title>Network Service Header (NSH)</title>
        <author>
            <name>P. Quinn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>U. Elzur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Service Function Chaining</kw>
            <kw>Network Service Header</kw>
            <kw>SFC</kw>
            <kw>NSH</kw>
            <kw>Network Service Function</kw>
        </keywords>
        <abstract><p>This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs).  The NSH also provides a mechanism for metadata exchange along the instantiated service paths.  The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).</p></abstract>
        <draft>draft-ietf-sfc-nsh-28</draft>
        <updated-by>
            <doc-id>RFC9451</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8300</errata-url>
        <doi>10.17487/RFC8300</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8301</doc-id>
        <title>Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)</title>
        <author>
            <name>S. Kitterman</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>email</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision.  This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.</p></abstract>
        <draft>draft-ietf-dcrup-dkim-usage-06</draft>
        <updates>
            <doc-id>RFC6376</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dcrup</wg_acronym>
        <doi>10.17487/RFC8301</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8302</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization</title>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>M. Umair</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>proxy</kw>
            <kw>RARP</kw>
            <kw>duplicate address</kw>
            <kw>DAD</kw>
            <kw>DHCP</kw>
            <kw>flooding</kw>
        </keywords>
        <abstract><p>This document describes mechanisms to optimize the Address Resolution Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent Interconnection of Lots of Links (TRILL) campus.  TRILL switches maintain a cache of IP / Media Access Control (MAC) address / Data Label bindings that are learned from ARP/ND requests and responses that pass through them.  In many cases, this cache allows an edge Routing Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it.  Such optimization reduces packet flooding over a TRILL campus.</p></abstract>
        <draft>draft-ietf-trill-arp-optimization-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8302</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8303</doc-id>
        <title>On the Usage of Transport Features Provided by IETF Transport Protocols</title>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>N. Khademi</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>56</page-count>
        <abstract><p>This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services.  It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism.  The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.</p></abstract>
        <draft>draft-ietf-taps-transports-usage-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8303</errata-url>
        <doi>10.17487/RFC8303</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8304</doc-id>
        <title>Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>T. Jones</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>UDP Transport</kw>
        </keywords>
        <abstract><p>This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols.  It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service.  RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services.  This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.</p></abstract>
        <draft>draft-ietf-taps-transports-usage-udp-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8304</errata-url>
        <doi>10.17487/RFC8304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8305</doc-id>
        <title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <date>
            <month>December</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IPv4</kw>
            <kw>TCP</kw>
            <kw>DNS</kw>
            <kw>NAT64</kw>
        </keywords>
        <abstract><p>Many communication protocols operating over the modern Internet use hostnames.  These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics.  Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly.  This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs".  This document obsoletes the original algorithm description in RFC 6555.</p></abstract>
        <draft>draft-ietf-v6ops-rfc6555bis-07</draft>
        <obsoletes>
            <doc-id>RFC6555</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8306</doc-id>
        <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths</title>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>D. Dhody</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Palleti</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>November</month>
            <year>2017</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.</p><p> This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.</p><p> This document obsoletes RFC 6006.</p></abstract>
        <draft>draft-ietf-pce-rfc6006bis-04</draft>
        <obsoletes>
            <doc-id>RFC6006</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9353</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8306</errata-url>
        <doi>10.17487/RFC8306</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8307</doc-id>
        <title>Well-Known URIs for the WebSocket Protocol</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>URI</kw>
            <kw>Web</kw>
            <kw>metadata</kw>
            <kw>well-known</kw>
            <kw>WebSocket</kw>
            <kw>ws</kw>
            <kw>wss</kw>
        </keywords>
        <abstract><p>RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs.  It was specifically defined for the "http" and "https" URI schemes.  The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes.</p></abstract>
        <draft>draft-bormann-hybi-ws-wk-00</draft>
        <updates>
            <doc-id>RFC6455</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8307</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8308</doc-id>
        <title>Extension Negotiation in the Secure Shell (SSH) Protocol</title>
        <author>
            <name>D. Bider</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ext-info</kw>
            <kw>ext-info-s</kw>
            <kw>ext-info-c</kw>
            <kw>SSH_MSG_EXT_INFO</kw>
            <kw>SSH_MSG_NEWCOMPRESS</kw>
            <kw>server-sig-algs</kw>
            <kw>delay-compression</kw>
            <kw>no-flow-control</kw>
            <kw>elevation</kw>
            <kw>delay compression</kw>
            <kw>delayed compression</kw>
            <kw>flow control</kw>
            <kw>elevated</kw>
        </keywords>
        <abstract><p>This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.</p></abstract>
        <draft>draft-ietf-curdle-ssh-ext-info-15</draft>
        <updates>
            <doc-id>RFC4251</doc-id>
            <doc-id>RFC4252</doc-id>
            <doc-id>RFC4253</doc-id>
            <doc-id>RFC4254</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9519</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8308</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8309</doc-id>
        <title>Service Models Explained</title>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
            <kw>Data Model</kw>
            <kw>SDN</kw>
            <kw>Software Defined Network</kw>
            <kw>Service Orchestrator</kw>
        </keywords>
        <abstract><p>The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.</p><p> A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).</p><p> This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.</p></abstract>
        <draft>draft-ietf-opsawg-service-model-explained-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC8309</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8310</doc-id>
        <title>Usage Profiles for DNS over TLS and DNS over DTLS</title>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>D. Gillmor</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>transport</kw>
        </keywords>
        <abstract><p>This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS).  These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS.  This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server.  Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS.  This document updates RFC 7858.</p></abstract>
        <draft>draft-ietf-dprive-dtls-and-tls-profiles-11</draft>
        <updates>
            <doc-id>RFC7858</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <doi>10.17487/RFC8310</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8311</doc-id>
        <title>Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation</title>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ECN</kw>
        </keywords>
        <abstract><p>This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints.  It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss.  This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas.  An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates.  In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622.  This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-experimentation-08</draft>
        <updates>
            <doc-id>RFC3168</doc-id>
            <doc-id>RFC4341</doc-id>
            <doc-id>RFC4342</doc-id>
            <doc-id>RFC5622</doc-id>
            <doc-id>RFC6679</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8311</errata-url>
        <doi>10.17487/RFC8311</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8312</doc-id>
        <title>CUBIC for Fast Long-Distance Networks</title>
        <author>
            <name>I. Rhee</name>
        </author>
        <author>
            <name>L. Xu</name>
        </author>
        <author>
            <name>S. Ha</name>
        </author>
        <author>
            <name>A. Zimmermann</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>R. Scheffenegger</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>CUBIC is an extension to the current TCP standards.  It differs from the current TCP standards only in the congestion control algorithm on the sender side.  In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks.  CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years.  This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.</p></abstract>
        <draft>draft-ietf-tcpm-cubic-07</draft>
        <obsoleted-by>
            <doc-id>RFC9438</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8312</errata-url>
        <doi>10.17487/RFC8312</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8313</doc-id>
        <title>Use of Multicast across Inter-domain Peering Points</title>
        <author>
            <name>P. Tarapore</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Sayko</name>
        </author>
        <author>
            <name>G. Shepherd</name>
        </author>
        <author>
            <name>T. Eckert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Krishnan</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>multicast security</kw>
            <kw>multicast troubleshooting</kw>
            <kw>multicast routing</kw>
            <kw>multicast tunneling</kw>
            <kw>PIM</kw>
            <kw>PIM-SSM</kw>
            <kw>SSM</kw>
            <kw>Source Specific Multicast</kw>
            <kw>AMT</kw>
            <kw>GRE</kw>
            <kw>Automatic Multicast Tunneling</kw>
            <kw>BGP</kw>
            <kw>MBGP</kw>
            <kw>M-BGP</kw>
            <kw>MP-BGP</kw>
            <kw>exchange</kw>
            <kw>exchange point</kw>
            <kw>NNI</kw>
            <kw>content distribution</kw>
            <kw>video streaming</kw>
            <kw>anycast</kw>
        </keywords>
        <abstract><p>This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios.  The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.</p></abstract>
        <draft>draft-ietf-mboned-interdomain-peering-bcp-14</draft>
        <is-also>
            <doc-id>BCP0213</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC8313</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8314</doc-id>
        <title>Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access</title>
        <author>
            <name>K. Moore</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>POP</kw>
            <kw>IMAP</kw>
            <kw>SMTP</kw>
            <kw>MSP</kw>
            <kw>mail submission</kw>
            <kw>STARTTLS</kw>
            <kw>DANE</kw>
            <kw>TLSA</kw>
        </keywords>
        <abstract><p>This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server.  This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.</p></abstract>
        <draft>draft-ietf-uta-email-deep-12</draft>
        <updates>
            <doc-id>RFC1939</doc-id>
            <doc-id>RFC2595</doc-id>
            <doc-id>RFC3501</doc-id>
            <doc-id>RFC5068</doc-id>
            <doc-id>RFC6186</doc-id>
            <doc-id>RFC6409</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8997</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8314</errata-url>
        <doi>10.17487/RFC8314</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8315</doc-id>
        <title>Cancel-Locks in Netnews Articles</title>
        <author>
            <name>M. Baeuerle</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Usenet</kw>
            <kw>Netnews</kw>
            <kw>Cancel-Lock</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles.  This document updates RFC 5537.</p></abstract>
        <draft>draft-baeuerle-netnews-cancel-lock-09</draft>
        <updates>
            <doc-id>RFC5537</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8315</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8316</doc-id>
        <title>Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations</title>
        <author>
            <name>J. Nobre</name>
        </author>
        <author>
            <name>L. Granville</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>A. Gonzalez Prieto</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Autonomic Networking</kw>
            <kw>SLA</kw>
            <kw>P2P</kw>
        </keywords>
        <abstract><p>This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements (SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.</p><p> This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes.</p></abstract>
        <draft>draft-irtf-nmrg-autonomic-sla-violation-detection-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8316</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8317</doc-id>
        <title>Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree).  A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network".  This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)".  This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.</p></abstract>
        <draft>draft-ietf-bess-evpn-etree-14</draft>
        <updates>
            <doc-id>RFC7385</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8318</doc-id>
        <title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee</title>
        <author>
            <name>S. Dawkins</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>nomcom</kw>
            <kw>IAOC</kw>
        </keywords>
        <abstract><p>This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee (NomCom) about the operations of the IETF Administrative Oversight Committee (IAOC).</p><p> This document updates RFC 7437.</p></abstract>
        <draft>draft-dawkins-iesg-nomcom-advisor-iaoc-03</draft>
        <obsoleted-by>
            <doc-id>RFC8713</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC7437</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8318</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8319</doc-id>
        <title>Support for Adjustable Maximum Router Lifetimes per Link</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements (RAs) from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.</p><p> This document specifies updates to the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.</p></abstract>
        <draft>draft-ietf-6man-maxra-04</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8319</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8320</doc-id>
        <title>LDP Extensions to Support Maximally Redundant Trees</title>
        <author>
            <name>A. Atlas</name>
        </author>
        <author>
            <name>K. Tiruveedhula</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>fast-reroute</kw>
            <kw>MRT</kw>
            <kw>MRT-FRR</kw>
        </keywords>
        <abstract><p>This document specifies extensions to the Label Distribution Protocol (LDP) to support the creation of Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as "MRT-FRR".</p><p> The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) and Label Edge Routers (LERs) advertising the MRT Capability.</p><p> MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.</p></abstract>
        <draft>draft-ietf-mpls-ldp-mrt-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8320</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8321</doc-id>
        <title>Alternate-Marking Method for Passive and Hybrid Performance Monitoring</title>
        <author>
            <name>G. Fioccola</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Capello</name>
        </author>
        <author>
            <name>M. Cociglio</name>
        </author>
        <author>
            <name>L. Castaldelli</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>L. Zheng</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>January</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Alternate Marking</kw>
            <kw>Marking Method</kw>
            <kw>Coloring Technique</kw>
        </keywords>
        <abstract><p>This document describes a method to perform packet loss, delay, and jitter measurements on live traffic.  This method is based on an Alternate-Marking (coloring) technique.  A report is provided in order to explain an example and show the method applicability.  This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.</p></abstract>
        <draft>draft-ietf-ippm-alt-mark-14</draft>
        <obsoleted-by>
            <doc-id>RFC9341</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8321</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8322</doc-id>
        <title>Resource-Oriented Lightweight Information Exchange (ROLIE)</title>
        <author>
            <name>J. Field</name>
        </author>
        <author>
            <name>S. Banghart</name>
        </author>
        <author>
            <name>D. Waltermire</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>syndication</kw>
            <kw>atom</kw>
            <kw>atom publishing protocol</kw>
            <kw>atom syndication format</kw>
            <kw>rest</kw>
            <kw>information sharing</kw>
            <kw>security automation</kw>
        </keywords>
        <abstract><p>This document defines a resource-oriented approach for security automation information publication, discovery, and sharing.  Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources.  Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories.  This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.</p></abstract>
        <draft>draft-ietf-mile-rolie-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC8322</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8323</doc-id>
        <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>S. Lemay</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>K. Hartke</name>
        </author>
        <author>
            <name>B. Silverajan</name>
        </author>
        <author>
            <name>B. Raymor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>Constrained Application Protocol</kw>
            <kw>REST</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>NAT Traversal</kw>
            <kw>CoAP in Browsers</kw>
        </keywords>
        <abstract><p>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</p><p> Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</p></abstract>
        <draft>draft-ietf-core-coap-tcp-tls-11</draft>
        <updates>
            <doc-id>RFC7641</doc-id>
            <doc-id>RFC7959</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8974</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8324</doc-id>
        <title>DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>domain name</kw>
            <kw>DNS functions</kw>
            <kw>DNS extensions</kw>
        </keywords>
        <abstract><p>The basic design of the Domain Name System was completed almost 30 years ago.  The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all.  This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.</p></abstract>
        <draft>draft-klensin-dns-function-considerations-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8324</errata-url>
        <doi>10.17487/RFC8324</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8325</doc-id>
        <title>Mapping Diffserv to IEEE 802.11</title>
        <author>
            <name>T. Szigeti</name>
        </author>
        <author>
            <name>J. Henry</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>quality of service</kw>
            <kw>QoS</kw>
            <kw>QoS classes</kw>
            <kw>mapping</kw>
            <kw>DSCP</kw>
            <kw>Diffserv</kw>
            <kw>Access Category</kw>
            <kw>AC</kw>
            <kw>User Priority</kw>
            <kw>UP</kw>
            <kw>802.11</kw>
            <kw>Wi-Fi</kw>
        </keywords>
        <abstract><p>As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default.  This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks.</p></abstract>
        <draft>draft-ietf-tsvwg-ieee-802-11-11</draft>
        <updated-by>
            <doc-id>RFC8622</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8325</errata-url>
        <doi>10.17487/RFC8325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8326</doc-id>
        <title>Graceful BGP Session Shutdown</title>
        <author>
            <name>P. Francois</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Pelsser</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document standardizes a new well-known BGP community, GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths.  This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance.</p></abstract>
        <draft>draft-ietf-grow-bgp-gshut-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8326</errata-url>
        <doi>10.17487/RFC8326</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8327</doc-id>
        <title>Mitigating the Negative Impact of Maintenance through BGP Session Culling</title>
        <author>
            <name>W. Hargrave</name>
        </author>
        <author>
            <name>M. Griswold</name>
        </author>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>N. Hilliard</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>culling</kw>
            <kw>EBGP</kw>
            <kw>sessions</kw>
        </keywords>
        <abstract><p>This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities.  It includes guidance for both IP networks and Internet Exchange Points (IXPs).  The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence.</p></abstract>
        <draft>draft-ietf-grow-bgp-session-culling-05</draft>
        <is-also>
            <doc-id>BCP0214</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8327</errata-url>
        <doi>10.17487/RFC8327</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8328</doc-id>
        <title>Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)</title>
        <author>
            <name>W. Liu</name>
        </author>
        <author>
            <name>C. Xie</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>G. Karagiannis</name>
        </author>
        <author>
            <name>M. Klyus</name>
        </author>
        <author>
            <name>J. Bi</name>
        </author>
        <author>
            <name>Y. Cheng</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Information models</kw>
            <kw>YANG data models</kw>
            <kw>Event Condition Action</kw>
            <kw>policy rules</kw>
            <kw>GPIM</kw>
            <kw>EPRIM</kw>
            <kw>declarative policy</kw>
            <kw>intent-based policy</kw>
        </keywords>
        <abstract><p>The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy.  These models point to device-, technology-, and service-specific YANG data models developed elsewhere.  Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element).  The network management function can then control the configuration and/or monitoring of network elements and services.  This document describes the SUPA basic framework, its elements, and interfaces.</p></abstract>
        <draft>draft-liu-policy-based-management-framework-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8328</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8329</doc-id>
        <title>Framework for Interface to Network Security Functions</title>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>E. Lopez</name>
        </author>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>R. Kumar</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>security policy</kw>
            <kw>security capability</kw>
        </keywords>
        <abstract><p>This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF.  Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.</p></abstract>
        <draft>draft-ietf-i2nsf-framework-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>i2nsf</wg_acronym>
        <doi>10.17487/RFC8329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8330</doc-id>
        <title>OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth</title>
        <author>
            <name>H. Long</name>
        </author>
        <author>
            <name>M. Ye</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>microwave</kw>
            <kw>copper</kw>
            <kw>Generalized SCSI-TLV</kw>
        </keywords>
        <abstract><p>A network may contain links with variable discrete bandwidth, e.g., microwave and copper.  The bandwidth of such links may change discretely in response to a changing external environment.  The word "availability" is typically used to describe such links during network planning.  This document defines a new type of Generalized Switching Capability-Specific Information (SCSI) TLV to extend the Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol.  The extension can be used for route computation in a network that contains links with variable discrete bandwidth.  Note that this document only covers the mechanisms by which the availability information is distributed.  The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document.  It is intended that technology-specific documents will reference this document to describe specific uses.</p></abstract>
        <draft>draft-ietf-ccamp-ospf-availability-extension-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC8330</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8331</doc-id>
        <title>RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data</title>
        <author>
            <name>T. Edwards</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>SDI</kw>
            <kw>video</kw>
            <kw>captions</kw>
            <kw>timecode</kw>
            <kw>ANC</kw>
        </keywords>
        <abstract><p>This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1.  SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).</p></abstract>
        <draft>draft-ietf-payload-rtp-ancillary-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8331</errata-url>
        <doi>10.17487/RFC8331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8332</doc-id>
        <title>Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol</title>
        <author>
            <name>D. Bider</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>rsa-sha2-256</kw>
            <kw>rsa-sha2-512</kw>
            <kw>ssh-rsa</kw>
            <kw>publickey</kw>
            <kw>server-sig-algs</kw>
            <kw>signature</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.</p></abstract>
        <draft>draft-ietf-curdle-rsa-sha2-12</draft>
        <updates>
            <doc-id>RFC4252</doc-id>
            <doc-id>RFC4253</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8332</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8333</doc-id>
        <title>Micro-loop Prevention by Introducing a Local Convergence Delay</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>P. Francois</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.</p><p> Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.</p><p> The mechanism is limited to the link-down event in order to keep the mechanism simple.</p><p> Simulations using real network topologies have been performed and show that local loops are a significant portion (&gt;50%) of the total forwarding loops.</p></abstract>
        <draft>draft-ietf-rtgwg-uloop-delay-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8333</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8334</doc-id>
        <title>Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>W. Tan</name>
        </author>
        <author>
            <name>G. Brown</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>Sunrise</kw>
            <kw>Landrush</kw>
            <kw>Trademark Clearinghouse</kw>
            <kw>Trademark Claims</kw>
            <kw>domain name registry</kw>
            <kw>launch phase</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry.</p></abstract>
        <draft>draft-ietf-regext-launchphase-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8334</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8335</doc-id>
        <title>PROBE: A Utility for Probing Interfaces</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <author>
            <name>C. Lenart</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>February</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Ping</kw>
            <kw>ICMP</kw>
        </keywords>
        <abstract><p>This document describes a network diagnostic tool called PROBE.  PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces.  Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface.  The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected.  This document updates RFC 4884.</p></abstract>
        <draft>draft-ietf-intarea-probe-10</draft>
        <updates>
            <doc-id>RFC4884</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC8335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8336</doc-id>
        <title>The ORIGIN HTTP/2 Frame</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>E. Nygren</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>connection coalescing</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.</p></abstract>
        <draft>draft-ietf-httpbis-origin-frame-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8336</errata-url>
        <doi>10.17487/RFC8336</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8337</doc-id>
        <title>Model-Based Metrics for Bulk Transport Capacity</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>performance</kw>
            <kw>bulk capacity</kw>
            <kw>BTC</kw>
            <kw>diagnostic</kw>
            <kw>statistics</kw>
        </keywords>
        <abstract><p>This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.</p><p> Model-Based Metrics rely on mathematical models to specify a Targeted IP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.</p><p> For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.</p></abstract>
        <draft>draft-ietf-ippm-model-based-metrics-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8337</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8338</doc-id>
        <title>Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP</title>
        <author>
            <name>S. Boutros</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sivabalan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP.  Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN.  A P2MP PW established via the proposed mechanism is root initiated.  This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.</p></abstract>
        <draft>draft-ietf-pals-p2mp-pw-04</draft>
        <updates>
            <doc-id>RFC7385</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8338</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8339</doc-id>
        <title>Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms</title>
        <author>
            <name>P. Jain</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Label Switched Path (LSP) Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks.  This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping.</p></abstract>
        <draft>draft-ietf-pals-p2mp-pw-lsp-ping-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC8339</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8340</doc-id>
        <title>YANG Tree Diagrams</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</p></abstract>
        <draft>draft-ietf-netmod-yang-tree-diagrams-06</draft>
        <updated-by>
            <doc-id>RFC8791</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0215</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8340</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8341</doc-id>
        <title>Network Configuration Access Control Model</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>NETCONF RESTCONF</kw>
            <kw>YANG</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</p><p> This document obsoletes RFC 6536.</p></abstract>
        <draft>draft-ietf-netconf-rfc6536bis-09</draft>
        <obsoletes>
            <doc-id>RFC6536</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0091</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8341</errata-url>
        <doi>10.17487/RFC8341</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8342</doc-id>
        <title>Network Management Datastore Architecture (NMDA)</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>P. Shafer</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>R. Wilton</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract><p>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF.  This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model.  This document updates RFC 7950.</p></abstract>
        <draft>draft-ietf-netmod-revised-datastores-10</draft>
        <updates>
            <doc-id>RFC7950</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8342</errata-url>
        <doi>10.17487/RFC8342</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8343</doc-id>
        <title>A YANG Data Model for Interface Management</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <abstract><p>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</p><p> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p><p> This document obsoletes RFC 7223.</p></abstract>
        <draft>draft-ietf-netmod-rfc7223bis-03</draft>
        <obsoletes>
            <doc-id>RFC7223</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8344</doc-id>
        <title>A YANG Data Model for IP Management</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.</p><p> The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</p><p> This document obsoletes RFC 7277.</p></abstract>
        <draft>draft-ietf-netmod-rfc7277bis-03</draft>
        <obsoletes>
            <doc-id>RFC7277</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8344</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8345</doc-id>
        <title>A YANG Data Model for Network Topologies</title>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>J. Medved</name>
        </author>
        <author>
            <name>R. Varga</name>
        </author>
        <author>
            <name>N. Bahadur</name>
        </author>
        <author>
            <name>H. Ananthakrishnan</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>topology</kw>
        </keywords>
        <abstract><p>This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories.  The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</p></abstract>
        <draft>draft-ietf-i2rs-yang-network-topo-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8345</errata-url>
        <doi>10.17487/RFC8345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8346</doc-id>
        <title>A YANG Data Model for Layer 3 Topologies</title>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>J. Medved</name>
        </author>
        <author>
            <name>R. Varga</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>H. Ananthakrishnan</name>
        </author>
        <author>
            <name>N. Bahadur</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>topology</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for Layer 3 network topologies.</p></abstract>
        <draft>draft-ietf-i2rs-yang-l3-topology-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC8346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8347</doc-id>
        <title>A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)</title>
        <author>
            <name>X. Liu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Kyparlis</name>
        </author>
        <author>
            <name>R. Parikh</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Routing</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document describes a data model for the Virtual Router Redundancy Protocol (VRRP).  Both versions 2 and 3 of VRRP are covered.</p></abstract>
        <draft>draft-ietf-rtgwg-yang-vrrp-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8348</doc-id>
        <title>A YANG Data Model for Hardware Management</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>ENTITY-MIB</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for the management of hardware on a single server.</p></abstract>
        <draft>draft-ietf-netmod-entity-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8348</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8349</doc-id>
        <title>A YANG Data Model for Routing Management (NMDA Version)</title>
        <author>
            <name>L. Lhotka</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>80</page-count>
        <keywords>
            <kw>configuration</kw>
            <kw>IPv6 Router Advertisements</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</p><p> The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.</p></abstract>
        <draft>draft-ietf-netmod-rfc8022bis-11</draft>
        <obsoletes>
            <doc-id>RFC8022</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8349</errata-url>
        <doi>10.17487/RFC8349</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8350</doc-id>
        <title>Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)</title>
        <author>
            <name>R. Zhang</name>
        </author>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>Z. Cao</name>
        </author>
        <author>
            <name>H. Deng</name>
        </author>
        <author>
            <name>Z. Du</name>
        </author>
        <date>
            <month>April</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Wi-Fi</kw>
            <kw>WLAN</kw>
            <kw>PMIP</kw>
            <kw>GRE</kw>
        </keywords>
        <abstract><p>Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC).  Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC.  When tunneled, a CAPWAP Data Channel is used for tunneling.  In many deployments, encapsulating data frames to an entity other than the AC (for example, to an Access Router (AR)) is desirable.  Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router.  This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation.  The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP.  The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP.</p></abstract>
        <draft>draft-ietf-opsawg-capwap-alt-tunnel-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC8350</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8351</doc-id>
        <title>The PKCS #8 EncryptedPrivateKeyInfo Media Type</title>
        <author>
            <name>S. Leonard</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8.  An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.</p></abstract>
        <draft>draft-seantek-pkcs8-encrypted-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8351</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8352</doc-id>
        <title>Energy-Efficient Features of Internet of Things Protocols</title>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>M. Kovatsch</name>
        </author>
        <author>
            <name>H. Tian</name>
        </author>
        <author>
            <name>Z. Cao</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>Radio Duty Cycling</kw>
            <kw>6LoWPAN</kw>
            <kw>6Lo</kw>
            <kw>CoAP</kw>
            <kw>RPL</kw>
        </keywords>
        <abstract><p>This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges.  It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior.  The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.</p></abstract>
        <draft>draft-ietf-lwig-energy-efficient-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC8352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8353</doc-id>
        <title>Generic Security Service API Version 2: Java Bindings Update</title>
        <author>
            <name>M. Upadhyay</name>
        </author>
        <author>
            <name>S. Malkani</name>
        </author>
        <author>
            <name>W. Wang</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>96</page-count>
        <keywords>
            <kw>JGSS</kw>
            <kw>GSS-API</kw>
        </keywords>
        <abstract><p>The Generic Security Services Application Programming Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2: Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.</p><p> The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121).</p></abstract>
        <draft>draft-ietf-kitten-rfc5653bis-07</draft>
        <obsoletes>
            <doc-id>RFC5653</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC8353</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8354</doc-id>
        <title>Use Cases for IPv6 Source Packet Routing in Networking (SPRING)</title>
        <author>
            <name>J. Brzozowski</name>
        </author>
        <author>
            <name>J. Leddy</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>R. Maglione</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Townsley</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm.  This document illustrates some use cases for Segment Routing in an IPv6-only environment.</p></abstract>
        <draft>draft-ietf-spring-ipv6-use-cases-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC8354</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8355</doc-id>
        <title>Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SEGMENT ROUTING</kw>
            <kw>RESILIENCY</kw>
            <kw>PROTECTION</kw>
            <kw>CONVERGENCE</kw>
        </keywords>
        <abstract><p>This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.</p></abstract>
        <draft>draft-ietf-spring-resiliency-use-cases-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8355</errata-url>
        <doi>10.17487/RFC8355</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8356</doc-id>
        <title>Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>PCEP</kw>
            <kw>IANA</kw>
            <kw>Experimental</kw>
        </keywords>
        <abstract><p>IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.</p><p> This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.</p></abstract>
        <draft>draft-ietf-pce-pcep-exp-codepoints-05</draft>
        <updates>
            <doc-id>RFC5440</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8356</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8357</doc-id>
        <title>Generalized UDP Source Port for DHCP Relay</title>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications.  The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.</p></abstract>
        <draft>draft-ietf-dhc-relay-port-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8357</errata-url>
        <doi>10.17487/RFC8357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8358</doc-id>
        <title>Update to Digital Signatures on Internet-Draft Documents</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>cms</kw>
            <kw>cryptographic message syntax</kw>
            <kw>detached signature</kw>
        </keywords>
        <abstract><p>RFC 5485 specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.</p><p> The RFC Editor recently published the first RFC that includes non- ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.</p><p> This document updates RFC 5485.</p></abstract>
        <draft>draft-housley-id-sig-update-03</draft>
        <updates>
            <doc-id>RFC5485</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8358</errata-url>
        <doi>10.17487/RFC8358</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8359</doc-id>
        <title>Network-Assigned Upstream Label</title>
        <author>
            <name>X. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Beeram</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP).  This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label.  This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.</p></abstract>
        <draft>draft-ietf-teas-network-assigned-upstream-label-12</draft>
        <updates>
            <doc-id>RFC3471</doc-id>
            <doc-id>RFC3473</doc-id>
            <doc-id>RFC6205</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8359</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8360</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Validation Reconsidered</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>C. Martinez</name>
        </author>
        <author>
            <name>T. Bruijnzeels</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>D. Shaw</name>
        </author>
        <date>
            <month>April</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.</p><p> The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.</p><p> It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.</p><p> This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.</p><p> Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.</p></abstract>
        <draft>draft-ietf-sidr-rpki-validation-reconsidered-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8360</errata-url>
        <doi>10.17487/RFC8360</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8361</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic</title>
        <author>
            <name>W. Hao</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>M. Durrani</name>
        </author>
        <author>
            <name>S. Gupta</name>
        </author>
        <author>
            <name>A. Qu</name>
        </author>
        <date>
            <month>April</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>RBridge</kw>
            <kw>CMT</kw>
            <kw>LAALP</kw>
        </keywords>
        <abstract><p>In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781.  This document describes a solution to resolve this RPF check failure issue through centralized replication.  All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation.  When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325).  To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required.  RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge.  This document updates RFC 6325.</p></abstract>
        <draft>draft-ietf-trill-centralized-replication-13</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8362</doc-id>
        <title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <author>
            <name>D. Goethals</name>
        </author>
        <author>
            <name>V. Reddy Vallem</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>April</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.</p><p> This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-lsa-extend-23</draft>
        <updates>
            <doc-id>RFC5340</doc-id>
            <doc-id>RFC5838</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC8362</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8363</doc-id>
        <title>GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks</title>
        <author>
            <name>X. Zhang</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>R. Casellas</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>flexi-grid</kw>
            <kw>OSPF-TE</kw>
            <kw>central frequency</kw>
            <kw>frequency slot</kw>
            <kw>channel spacing</kw>
        </keywords>
        <abstract><p>The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as "flexi-grid".</p><p> Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.</p></abstract>
        <draft>draft-ietf-ccamp-flexible-grid-ospf-ext-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC8363</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8364</doc-id>
        <title>PIM Flooding Mechanism (PFM) and Source Discovery (SD)</title>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>M. Brig</name>
        </author>
        <author>
            <name>A. Jonasson</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources.  Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding.  This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees.  Multicast source information is flooded throughout the multicast domain using a new generic PIM Flooding Mechanism (PFM).  This allows LHRs to learn about new sources without receiving initial data packets.</p></abstract>
        <draft>draft-ietf-pim-source-discovery-bsr-12</draft>
        <updated-by>
            <doc-id>RFC8736</doc-id>
            <doc-id>RFC9436</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8364</errata-url>
        <doi>10.17487/RFC8364</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8365</doc-id>
        <title>A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Drake</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Bitar</name>
        </author>
        <author>
            <name>R. Shekhar</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>March</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>EVPN Control Plane with VxLAN Encapsulation</kw>
            <kw>EVPN Control Plane with NvGRE Encapsulation</kw>
        </keywords>
        <abstract><p>This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures.  In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE.  This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document.  This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal.  It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.</p></abstract>
        <draft>draft-ietf-bess-evpn-overlay-12</draft>
        <updated-by>
            <doc-id>RFC9746</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8365</errata-url>
        <doi>10.17487/RFC8365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8366</doc-id>
        <title>A Voucher Artifact for Bootstrapping Protocols</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>M. Pritikin</name>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>voucher</kw>
            <kw>autonomic networking</kw>
            <kw>autonomous operation</kw>
            <kw>self-management</kw>
        </keywords>
        <abstract><p>This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".</p><p> This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).</p><p> This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</p></abstract>
        <draft>draft-ietf-anima-voucher-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8366</errata-url>
        <doi>10.17487/RFC8366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8367</doc-id>
        <title>Wrongful Termination of Internet Protocol (IP) Packets</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>J. Yallouz</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>Routers and middleboxes terminate packets for various reasons.  In some cases, these packets are wrongfully terminated.  This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.</p></abstract>
        <draft>draft-tj-wrongful-termination-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8367</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8368</doc-id>
        <title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
        <author>
            <name>T. Eckert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Behringer</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>autonomic networking</kw>
            <kw>autonomous operation</kw>
            <kw>self-management</kw>
        </keywords>
        <abstract><p>Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.</p><p> Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</p><p> This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.</p></abstract>
        <draft>draft-ietf-anima-stable-connectivity-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <doi>10.17487/RFC8368</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8369</doc-id>
        <title>Internationalizing IPv6 Using 128-Bit Unicode</title>
        <author>
            <name>H. Kaplan</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed.  Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits.  This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.</p></abstract>
        <draft>draft-kaplan-unicode-ipv6-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8369</errata-url>
        <doi>10.17487/RFC8369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8370</doc-id>
        <title>Techniques to Improve the Scalability of RSVP-TE Deployments</title>
        <author>
            <name>V. Beeram</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <author>
            <name>D. Pacella</name>
        </author>
        <author>
            <name>T. Saad</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>RSVP-TE Scaling</kw>
            <kw>RI-RSVP</kw>
            <kw>Per-Peer Flow Control</kw>
        </keywords>
        <abstract><p>Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.</p><p> This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.</p></abstract>
        <draft>draft-ietf-teas-rsvp-te-scaling-rec-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8370</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8371</doc-id>
        <title>Mobile Node Identifier Types for MIPv6</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Mobility</kw>
            <kw>IPv6</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract><p>This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.</p></abstract>
        <draft>draft-ietf-dmm-4283mnids-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8371</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8372</doc-id>
        <title>MPLS Flow Identification Considerations</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>OAM</kw>
            <kw>performance monitoring</kw>
            <kw>flow identification</kw>
        </keywords>
        <abstract><p>This document discusses aspects to consider when developing a solution for MPLS flow identification.  The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.</p></abstract>
        <draft>draft-ietf-mpls-flow-ident-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8373</doc-id>
        <title>Negotiating Human Language in Real-Time Communications</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>language</kw>
            <kw>human language</kw>
            <kw>SIP</kw>
            <kw>SLIM</kw>
        </keywords>
        <abstract><p>Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).</p><p> This document describes the need as well as a solution that uses new SDP media attributes.</p></abstract>
        <draft>draft-ietf-slim-negotiating-human-language-24</draft>
        <updated-by>
            <doc-id>RFC8865</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>slim</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8373</errata-url>
        <doi>10.17487/RFC8373</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8374</doc-id>
        <title>BGPsec Design Choices and Summary of Supporting Discussions</title>
        <author>
            <name>K. Sriram</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>Internet Routing Security</kw>
        </keywords>
        <abstract><p>This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification).  The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice.  This document also presents brief summaries of the arguments that aided the decision process.  Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205.  These notes highlight the differences and provide pointers to details and rationale regarding those design changes.</p></abstract>
        <draft>draft-sriram-bgpsec-design-choices-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8374</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8375</doc-id>
        <title>Special-Use Domain 'home.arpa.'</title>
        <author>
            <name>P. Pfister</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Homenet</kw>
            <kw>TLD</kw>
            <kw>RFC6761</kw>
            <kw>.home.arpa</kw>
        </keywords>
        <abstract><p>This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks.  The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.</p></abstract>
        <draft>draft-ietf-homenet-dot-14</draft>
        <updates>
            <doc-id>RFC7788</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8375</errata-url>
        <doi>10.17487/RFC8375</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8376</doc-id>
        <title>Low-Power Wide Area Network (LPWAN) Overview</title>
        <author>
            <name>S. Farrell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>Low Power Wide Area Network Overview</kw>
        </keywords>
        <abstract><p>Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation.  This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.</p></abstract>
        <draft>draft-ietf-lpwan-overview-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC8376</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8377</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Multi-Topology</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120.  This document updates RFCs 6325 and 7177.</p></abstract>
        <draft>draft-ietf-trill-multi-topology-06</draft>
        <updates>
            <doc-id>RFC6325</doc-id>
            <doc-id>RFC7177</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8377</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8378</doc-id>
        <title>Signal-Free Locator/ID Separation Protocol (LISP) Multicast</title>
        <author>
            <name>V. Moreno</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>LISP</kw>
            <kw>deployment</kw>
        </keywords>
        <abstract><p>When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members.  When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites.  The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.</p></abstract>
        <draft>draft-ietf-lisp-signal-free-multicast-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC8378</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8379</doc-id>
        <title>OSPF Graceful Link Shutdown</title>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>P. Sarkar</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>M. Nanduri</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>IGP</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.</p><p> It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.</p><p> This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.</p></abstract>
        <draft>draft-ietf-ospf-link-overload-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <doi>10.17487/RFC8379</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8380</doc-id>
        <title>Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation</title>
        <author>
            <name>L. Dunbar</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Directory</kw>
            <kw>Nickname</kw>
        </keywords>
        <abstract><p>This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service.</p></abstract>
        <draft>draft-ietf-trill-directory-assisted-encap-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8380</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8381</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>W. Hao</name>
        </author>
        <author>
            <name>A. Banerjee</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>OUI</kw>
            <kw>CID</kw>
        </keywords>
        <abstract><p>The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges (Routing Bridges).  TRILL includes a general mechanism, called an RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link.  This document specifies a method to send vendor-specific messages over the RBridge Channel facility.</p></abstract>
        <draft>draft-ietf-trill-vendor-channel-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8381</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8382</doc-id>
        <title>Shared Bottleneck Detection for Coupled Congestion Control for RTP Media</title>
        <author>
            <name>D. Hayes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Ferlin</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>K. Hiorth</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>SBD</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck.  This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.</p></abstract>
        <draft>draft-ietf-rmcat-sbd-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8382</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8383</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL): Address Flush Message</title>
        <author>
            <name>W. Hao</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>M. Umair</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>convergence</kw>
            <kw>VLAN</kw>
            <kw>data label</kw>
            <kw>FGL</kw>
        </keywords>
        <abstract><p>The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.</p><p> This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change.</p></abstract>
        <draft>draft-ietf-trill-address-flush-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8383</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8384</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes</title>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>F. Hu</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>T. Liao</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>TRILL</kw>
            <kw>Smart Endnode</kw>
        </keywords>
        <abstract><p>This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation.  Such an endnode is known as a "Smart Endnode".  Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode".  The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames.  The solution also enables endnodes that are Fine-Grained Label (FGL) aware.</p></abstract>
        <draft>draft-ietf-trill-smart-endnodes-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8384</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8385</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS</title>
        <author>
            <name>M. Umair</name>
        </author>
        <author>
            <name>S. Kingston Smiler</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>L. Yong</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>VPLS</kw>
            <kw>VPTS</kw>
            <kw>TIR</kw>
        </keywords>
        <abstract><p>This document specifies methods to interconnect multiple TRILL (Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (Virtual Private LAN Service) standards.  This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network.</p></abstract>
        <draft>draft-ietf-trill-transport-over-mpls-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8385</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8386</doc-id>
        <title>Privacy Considerations for Protocols Relying on IP Broadcast or Multicast</title>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>M. Faath</name>
        </author>
        <author>
            <name>F. Weisshaar</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IP broadcasts</kw>
            <kw>multicast</kw>
            <kw>privacy considerations</kw>
        </keywords>
        <abstract><p>A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution.  Some of these functions can only be implemented efficiently using such mechanisms.  When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content.  Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.</p></abstract>
        <draft>draft-ietf-intarea-broadcast-consider-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC8386</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8387</doc-id>
        <title>Practical Considerations and Implementation Experiences in Securing Smart Object Networks</title>
        <author>
            <name>M. Sethi</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>H. Back</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>security</kw>
            <kw>integrity</kw>
            <kw>signing</kw>
            <kw>ECC</kw>
            <kw>CoAP</kw>
            <kw>asymmetric</kw>
            <kw>cryptography</kw>
        </keywords>
        <abstract><p>This memo describes challenges associated with securing resource- constrained smart object devices.  The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices.  Lastly, the memo discusses trade-offs involving different types of security approaches.</p></abstract>
        <draft>draft-ietf-lwig-crypto-sensors-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC8387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8388</doc-id>
        <title>Usage and Applicability of BGP MPLS-Based Ethernet VPN</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Palislamovic</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>EVPN</kw>
        </keywords>
        <abstract><p>This document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario.  The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option.  This document is intended to provide a simplified guide for the deployment of EVPN networks.</p></abstract>
        <draft>draft-ietf-bess-evpn-usage-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8388</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8389</doc-id>
        <title>Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E)</title>
        <author>
            <name>Y. Fu</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>B. Liu</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>Y. Chen</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>MAP</kw>
        </keywords>
        <abstract><p>This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.</p></abstract>
        <draft>draft-ietf-softwire-map-mib-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8390</doc-id>
        <title>RSVP-TE Path Diversity Using Exclude Route</title>
        <author>
            <name>Z. Ali</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Beller</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>LSP diversity</kw>
        </keywords>
        <abstract><p>RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS).</p><p> For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.</p></abstract>
        <draft>draft-ietf-teas-lsp-diversity-10</draft>
        <updates>
            <doc-id>RFC4874</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8390</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8391</doc-id>
        <title>XMSS: eXtended Merkle Signature Scheme</title>
        <author>
            <name>A. Huelsing</name>
        </author>
        <author>
            <name>D. Butin</name>
        </author>
        <author>
            <name>S. Gazdag</name>
        </author>
        <author>
            <name>J. Rijneveld</name>
        </author>
        <author>
            <name>A. Mohaisen</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>Digital signature</kw>
            <kw>cryptography</kw>
            <kw>post-quantum cryptography</kw>
            <kw>Hash-based signatures</kw>
            <kw>Merkle signatures</kw>
            <kw>Merkle tree</kw>
            <kw>hash function</kw>
            <kw>Winternitz</kw>
            <kw>Winternitz one-time signature scheme</kw>
            <kw>WOTS</kw>
            <kw>W-OTS</kw>
            <kw>WOTS+</kw>
            <kw>W-OTS+</kw>
            <kw>XMSS-MT</kw>
            <kw>multi-tree XMSS</kw>
        </keywords>
        <abstract><p>This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature.  This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS.  Both XMSS and XMSS^MT use WOTS+ as a main building block.  XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems.  Instead, it is proven that it only relies on the properties of cryptographic hash functions.  XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken.  It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks.  Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.</p></abstract>
        <draft>draft-irtf-cfrg-xmss-hash-based-signatures-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8391</errata-url>
        <doi>10.17487/RFC8391</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8392</doc-id>
        <title>CBOR Web Token (CWT)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>E. Wahlstroem</name>
        </author>
        <author>
            <name>S. Erdtman</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>Claims</kw>
            <kw>Concise Binary Object Representation</kw>
            <kw>CBOR</kw>
            <kw>CBOR Object Signing and Encryption</kw>
            <kw>COSE</kw>
            <kw>OAuth</kw>
            <kw>ACE</kw>
        </keywords>
        <abstract><p>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties.  The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection.  A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value.  CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</p></abstract>
        <draft>draft-ietf-ace-cbor-web-token-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8392</errata-url>
        <doi>10.17487/RFC8392</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8393</doc-id>
        <title>Operating the Network Service Header (NSH) with Next Protocol "None"</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Service Function Chaining</kw>
            <kw>Network Service Header</kw>
            <kw>Metadata</kw>
        </keywords>
        <abstract><p>This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None".</p><p> This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.</p></abstract>
        <draft>draft-farrel-sfc-convent-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC8393</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8394</doc-id>
        <title>Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements</title>
        <author>
            <name>Y. Li</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>L. Kreeger</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>NVO3</kw>
            <kw>VDP</kw>
        </keywords>
        <abstract><p>In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.</p><p> One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements.</p></abstract>
        <draft>draft-ietf-nvo3-hpvr2nve-cp-req-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC8394</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8395</doc-id>
        <title>Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>J. Liste</name>
        </author>
        <author>
            <name>B. Wen</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures.  These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks (L2VPNs).  This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.</p></abstract>
        <draft>draft-ietf-bess-fat-pw-bgp-04</draft>
        <updates>
            <doc-id>RFC4761</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8395</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8396</doc-id>
        <title>Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>T. McGarry</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Problem Statement</kw>
            <kw>Real-Time Communication</kw>
        </keywords>
        <abstract><p>The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet.  This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs).  TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement.  This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs.</p></abstract>
        <draft>draft-ietf-modern-problem-framework-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>modern</wg_acronym>
        <doi>10.17487/RFC8396</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8397</doc-id>
        <title>Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames</title>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>H. Zhai</name>
        </author>
        <author>
            <name>D. Liu</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Aggregated</kw>
            <kw>Global Tree</kw>
            <kw>Local Tree</kw>
        </keywords>
        <abstract><p>TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing.  Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243.  This document specifies a unique nickname approach.  This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.</p></abstract>
        <draft>draft-ietf-trill-multilevel-unique-nickname-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8397</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8398</doc-id>
        <title>Internationalized Email Addresses in X.509 Certificates</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Chuang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>PKIX</kw>
            <kw>emal address</kw>
        </keywords>
        <abstract><p>This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.</p><p> This document updates RFC 5280.</p></abstract>
        <draft>draft-ietf-lamps-eai-addresses-18</draft>
        <obsoleted-by>
            <doc-id>RFC9598</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8398</errata-url>
        <doi>10.17487/RFC8398</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8399</doc-id>
        <title>Internationalization Updates to RFC 5280</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.</p></abstract>
        <draft>draft-ietf-lamps-rfc5280-i18n-update-04</draft>
        <obsoleted-by>
            <doc-id>RFC9549</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8399</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8400</doc-id>
        <title>Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection</title>
        <author>
            <name>H. Chen</name>
        </author>
        <author>
            <name>A. Liu</name>
        </author>
        <author>
            <name>T. Saad</name>
        </author>
        <author>
            <name>F. Xu</name>
        </author>
        <author>
            <name>L. Huang</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>FRR</kw>
            <kw>Fast Reroute</kw>
        </keywords>
        <abstract><p>This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).</p></abstract>
        <draft>draft-ietf-teas-rsvp-egress-protection-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8400</errata-url>
        <doi>10.17487/RFC8400</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8401</doc-id>
        <title>Bit Index Explicit Replication (BIER) Support via IS-IS</title>
        <author>
            <name>L. Ginsberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.</p></abstract>
        <draft>draft-ietf-bier-isis-extensions-11</draft>
        <updated-by>
            <doc-id>RFC9272</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8401</errata-url>
        <doi>10.17487/RFC8401</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8402</doc-id>
        <title>Segment Routing Architecture</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</p><p> SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</p><p> SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</p></abstract>
        <draft>draft-ietf-spring-segment-routing-15</draft>
        <updated-by>
            <doc-id>RFC9256</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8402</errata-url>
        <doi>10.17487/RFC8402</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8403</doc-id>
        <title>A Scalable and Topology-Aware MPLS Data-Plane Monitoring System</title>
        <author>
            <name>R. Geib</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Kumar</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Segment based Routing</kw>
            <kw>OAM</kw>
            <kw>LSP surveillance</kw>
            <kw>MPLS monitoring</kw>
        </keywords>
        <abstract><p>This document describes features of an MPLS path monitoring system and related use cases.  Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain.  The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way.  MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.</p></abstract>
        <draft>draft-ietf-spring-oam-usecase-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC8403</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8404</doc-id>
        <title>Effects of Pervasive Encryption on Operators</title>
        <author>
            <name>K. Moriarty</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Morton</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
            <kw>Monitoring</kw>
            <kw>Management</kw>
            <kw>Security Management</kw>
            <kw>Operations</kw>
        </keywords>
        <abstract><p>Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities.  RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed.  This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.</p></abstract>
        <draft>draft-mm-wg-effect-encrypt-25</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8404</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8405</doc-id>
        <title>Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs</title>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>P. Francois</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.</p><p> Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events.</p></abstract>
        <draft>draft-ietf-rtgwg-backoff-algo-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8405</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8406</doc-id>
        <title>Taxonomy of Coding Techniques for Efficient Network Communications</title>
        <author>
            <name>B. Adamson</name>
        </author>
        <author>
            <name>C. Adjih</name>
        </author>
        <author>
            <name>J. Bilbao</name>
        </author>
        <author>
            <name>V. Firoiu</name>
        </author>
        <author>
            <name>F. Fitzek</name>
        </author>
        <author>
            <name>S. Ghanem</name>
        </author>
        <author>
            <name>E. Lochin</name>
        </author>
        <author>
            <name>A. Masucci</name>
        </author>
        <author>
            <name>M-J. Montpetit</name>
        </author>
        <author>
            <name>M. Pedersen</name>
        </author>
        <author>
            <name>G. Peralta</name>
        </author>
        <author>
            <name>V. Roca</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Saxena</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Network Coding</kw>
            <kw>Taxonomy</kw>
        </keywords>
        <abstract><p>This document summarizes recommended terminology for Network Coding concepts and constructs.  It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents on Network Coding.  This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.</p></abstract>
        <draft>draft-irtf-nwcrg-network-coding-taxonomy-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8406</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8407</doc-id>
        <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>NETMOD</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This memo provides guidelines for authors and reviewers of specifications containing YANG modules.  Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules.  This document obsoletes RFC 6087.</p></abstract>
        <draft>draft-ietf-netmod-rfc6087bis-20</draft>
        <obsoletes>
            <doc-id>RFC6087</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8819</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0216</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8407</errata-url>
        <doi>10.17487/RFC8407</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8408</doc-id>
        <title>Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages</title>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>R. Varga</name>
        </author>
        <author>
            <name>J. Hardwick</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints.  Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol.  However, other TE path setup methods are possible within the PCE architecture.  This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.</p></abstract>
        <draft>draft-ietf-pce-lsp-setup-type-10</draft>
        <updated-by>
            <doc-id>RFC8664</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8408</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8409</doc-id>
        <title>The Entity Category Security Assertion Markup Language (SAML) Attribute Types</title>
        <author>
            <name>I. Young</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Johansson</name>
        </author>
        <author>
            <name>S. Cantor</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>REFEDS</kw>
        </keywords>
        <abstract><p>This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.</p><p> This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group.</p></abstract>
        <draft>draft-young-entity-category-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8409</errata-url>
        <doi>10.17487/RFC8409</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8410</doc-id>
        <title>Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Elliptic Curve Cryptography</kw>
            <kw>Curve25519</kw>
            <kw>Curve448</kw>
            <kw>Goldilocks</kw>
            <kw>X.509</kw>
            <kw>PKIX</kw>
            <kw>PKI</kw>
            <kw>OID</kw>
            <kw>ASN.1</kw>
            <kw>EdDSA</kw>
            <kw>Ed25519</kw>
            <kw>Ed448</kw>
            <kw>X25519</kw>
            <kw>X448</kw>
        </keywords>
        <abstract><p>This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves.  The signature algorithms covered are Ed25519 and Ed448.  The key agreement algorithms covered are X25519 and X448.  The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.</p></abstract>
        <draft>draft-ietf-curdle-pkix-10</draft>
        <updated-by>
            <doc-id>RFC9295</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8410</errata-url>
        <doi>10.17487/RFC8410</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8411</doc-id>
        <title>IANA Registration for the Cryptographic Algorithm Object Identifier Range</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>R. Andrews</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc.  for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms.  This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs.  This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.</p></abstract>
        <draft>draft-schaad-curdle-oid-registry-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8412</doc-id>
        <title>Software Inventory Message and Attributes (SWIMA) for PA-TNC</title>
        <author>
            <name>C. Schmidt</name>
        </author>
        <author>
            <name>D. Haynes</name>
        </author>
        <author>
            <name>C. Coffin</name>
        </author>
        <author>
            <name>D. Waltermire</name>
        </author>
        <author>
            <name>J. Fitzgerald-McKay</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>101</page-count>
        <keywords>
            <kw>SWID</kw>
            <kw>PA-TNC</kw>
            <kw>NEA</kw>
            <kw>Software inventory</kw>
        </keywords>
        <abstract><p>This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).</p></abstract>
        <draft>draft-ietf-sacm-nea-swima-patnc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacm</wg_acronym>
        <doi>10.17487/RFC8412</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8413</doc-id>
        <title>Framework for Scheduled Use of Resources</title>
        <author>
            <name>Y. Zhuang</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>H. Chen</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Traffic Engineering</kw>
            <kw>TE</kw>
            <kw>Label Switched Path</kw>
            <kw>LSP</kw>
            <kw>MPLS</kw>
            <kw>Path Computation Element</kw>
            <kw>PCE</kw>
            <kw>Software Defined Networking</kw>
            <kw>SDN</kw>
        </keywords>
        <abstract><p>Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future.  This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources.  This document does not describe specific protocols or protocol extensions needed to realize this service.</p></abstract>
        <draft>draft-ietf-teas-scheduled-resources-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8413</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8414</doc-id>
        <title>OAuth 2.0 Authorization Server Metadata</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>N. Sakimura</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>Discovery</kw>
            <kw>Metadata</kw>
            <kw>Discovery Metadata</kw>
            <kw>Configuration Information</kw>
            <kw>Authorization Server</kw>
            <kw>WebFinger</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
        </keywords>
        <abstract><p>This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.</p></abstract>
        <draft>draft-ietf-oauth-discovery-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8414</errata-url>
        <doi>10.17487/RFC8414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8415</doc-id>
        <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>M. Siodelski</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>A. Yourtchenko</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>T. Winters</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>154</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>IPv6</kw>
            <kw>DHCP</kw>
        </keywords>
        <abstract><p>This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).</p><p> This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</p></abstract>
        <draft>draft-ietf-dhc-rfc3315bis-13</draft>
        <obsoletes>
            <doc-id>RFC3315</doc-id>
            <doc-id>RFC3633</doc-id>
            <doc-id>RFC3736</doc-id>
            <doc-id>RFC4242</doc-id>
            <doc-id>RFC7083</doc-id>
            <doc-id>RFC7283</doc-id>
            <doc-id>RFC7550</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8415</errata-url>
        <doi>10.17487/RFC8415</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8416</doc-id>
        <title>Simplified Local Internet Number Resource Management with the RPKI (SLURM)</title>
        <author>
            <name>D. Ma</name>
        </author>
        <author>
            <name>D. Mandelberg</name>
        </author>
        <author>
            <name>T. Bruijnzeels</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>Local Trust Anchor</kw>
            <kw>BGPsec</kw>
        </keywords>
        <abstract><p>The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources.  Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions.  ISPs can also use the RPKI to validate the path of a BGP route.  However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions.  The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.</p></abstract>
        <draft>draft-ietf-sidr-slurm-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sidr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8416</errata-url>
        <doi>10.17487/RFC8416</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8417</doc-id>
        <title>Security Event Token (SET)</title>
        <author>
            <name>P. Hunt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>W. Denniss</name>
        </author>
        <author>
            <name>M. Ansari</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Identity</kw>
            <kw>Security</kw>
            <kw>Event</kw>
            <kw>Token</kw>
            <kw>Claims</kw>
            <kw>JSON</kw>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
        </keywords>
        <abstract><p>This specification defines the Security Event Token (SET) data structure.  A SET describes statements of fact from the perspective of an issuer about a subject.  These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject.  This specification is intended to enable representing security- and identity-related events.  A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted.  SETs can be distributed via protocols such as HTTP.</p></abstract>
        <draft>draft-ietf-secevent-token-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secevent</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8417</errata-url>
        <doi>10.17487/RFC8417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8418</doc-id>
        <title>Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).</p></abstract>
        <draft>draft-ietf-curdle-cms-ecdh-new-curves-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8418</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8419</doc-id>
        <title>Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS).  For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes.  However, the HashEdDSA mode is not used with the CMS.  In addition, no context string is used with the CMS.</p></abstract>
        <draft>draft-ietf-curdle-cms-eddsa-signatures-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8419</errata-url>
        <doi>10.17487/RFC8419</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8420</doc-id>
        <title>Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).</p></abstract>
        <draft>draft-ietf-ipsecme-eddsa-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8420</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8421</doc-id>
        <title>Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)</title>
        <author>
            <name>P. Martinsen</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>P. Patil</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist.  The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).</p></abstract>
        <draft>draft-ietf-ice-dualstack-fairness-07</draft>
        <is-also>
            <doc-id>BCP0217</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ice</wg_acronym>
        <doi>10.17487/RFC8421</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8422</doc-id>
        <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>M. Pegourie-Gonnard</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>ECDSA</kw>
            <kw>EdDSA</kw>
        </keywords>
        <abstract><p>This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.</p><p> This document obsoletes RFC 4492.</p></abstract>
        <draft>draft-ietf-tls-rfc4492bis-17</draft>
        <obsoletes>
            <doc-id>RFC4492</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8996</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8422</errata-url>
        <doi>10.17487/RFC8422</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8423</doc-id>
        <title>Reclassification of Suite B Documents to Historic Status</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>L. Zieglar</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>x.509 v3 certificates</kw>
            <kw>x.509 v2 certificate revocation lists</kw>
            <kw>crl</kw>
            <kw>UI suites</kw>
            <kw>user interface suites</kw>
            <kw>elliptic curve</kw>
            <kw>ike</kw>
            <kw>cryptographic algorithm policy</kw>
            <kw>security application</kw>
            <kw>suite b cryptography</kw>
            <kw>cmc</kw>
            <kw>suite b x.509 public key certificates</kw>
            <kw>cryptographic algorithm policy</kw>
            <kw>nsa</kw>
        </keywords>
        <abstract><p>This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so.  This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460.  In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430.</p></abstract>
        <draft>draft-housley-suite-b-to-historic-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8423</errata-url>
        <doi>10.17487/RFC8423</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8424</doc-id>
        <title>Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection</title>
        <author>
            <name>H. Chen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Torvi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Head Protection</kw>
        </keywords>
        <abstract><p>This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).  It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP.  The procedures described in this document are experimental.</p></abstract>
        <draft>draft-ietf-teas-rsvp-ingress-protection-17</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8425</doc-id>
        <title>IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags</title>
        <author>
            <name>O. Troan</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1).  RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861.  The purpose of this document is to create an IANA registry for the PIO flags.  This document updates RFC 4861.</p></abstract>
        <draft>draft-ietf-6man-ndpioiana-04</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8426</doc-id>
        <title>Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence</title>
        <author>
            <name>H. Sitaraman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs.  In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs.  For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network.  Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent.  The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.</p></abstract>
        <draft>draft-ietf-teas-sr-rsvp-coexistence-rec-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8427</doc-id>
        <title>Representing DNS Messages in JSON</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>Some applications use DNS messages, or parts of DNS messages, as data.  For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time.  Another example is a system that puts together DNS queries and responses from message parts.  This document describes a general format for DNS message data in JSON.  Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.</p></abstract>
        <draft>draft-hoffman-dns-in-json-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8427</errata-url>
        <doi>10.17487/RFC8427</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8428</doc-id>
        <title>Sensor Measurement Lists (SenML)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>Z. Shelby</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>data model</kw>
        </keywords>
        <abstract><p>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML).  Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model.  A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</p></abstract>
        <draft>draft-ietf-core-senml-16</draft>
        <updated-by>
            <doc-id>RFC9100</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8428</errata-url>
        <doi>10.17487/RFC8428</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8429</doc-id>
        <title>Deprecate Triple-DES (3DES) and RC4 in Kerberos</title>
        <author>
            <name>B. Kaduk</name>
        </author>
        <author>
            <name>M. Short</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>GSS-API</kw>
            <kw>GSS</kw>
        </keywords>
        <abstract><p>The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos.  Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types.  RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.</p></abstract>
        <draft>draft-ietf-curdle-des-des-des-die-die-die-05</draft>
        <updates>
            <doc-id>RFC3961</doc-id>
            <doc-id>RFC4120</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0218</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8429</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8430</doc-id>
        <title>RIB Information Model</title>
        <author>
            <name>N. Bahadur</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Kini</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Medved</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>RIB</kw>
            <kw>info model</kw>
        </keywords>
        <abstract><p>Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB).  Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding.  This document specifies an information model for the RIB to enable defining a standardized data model.  The IETF's I2RS WG used this document to design the I2RS RIB data model.  This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.</p></abstract>
        <draft>draft-ietf-i2rs-rib-info-model-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <doi>10.17487/RFC8430</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8431</doc-id>
        <title>A YANG Data Model for the Routing Information Base (RIB)</title>
        <author>
            <name>L. Wang</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>A. Dass</name>
        </author>
        <author>
            <name>H. Ananthakrishnan</name>
        </author>
        <author>
            <name>S. Kini</name>
        </author>
        <author>
            <name>N. Bahadur</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>71</page-count>
        <abstract><p>This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model.</p></abstract>
        <draft>draft-ietf-i2rs-rib-data-model-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8431</errata-url>
        <doi>10.17487/RFC8431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8432</doc-id>
        <title>A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters</title>
        <author>
            <name>J. Ahlberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Ye</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>LM. Contreras</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Microwave</kw>
            <kw>millimeter waves</kw>
            <kw>YANG Model</kw>
            <kw>interface management</kw>
        </keywords>
        <abstract><p>The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.</p><p> This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG data model.</p><p> The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology.</p></abstract>
        <draft>draft-ietf-ccamp-microwave-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC8432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8433</doc-id>
        <title>A Simpler Method for Resolving Alert-Info URNs</title>
        <author>
            <name>D. Worley</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>Alert-Info</kw>
            <kw>audio signals</kw>
            <kw>call signaling</kw>
            <kw>call transfer</kw>
            <kw>resolution</kw>
            <kw>signaling</kw>
            <kw>signals</kw>
            <kw>SIP</kw>
            <kw>URN</kw>
            <kw>visual signals</kw>
        </keywords>
        <abstract><p>The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.</p><p> RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.</p></abstract>
        <draft>draft-worley-alert-info-fsm-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8433</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8434</doc-id>
        <title>Requirements for Parallel NFS (pNFS) Layout Types</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661.  In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout.  The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types.  In this regard, this document updates RFC 5661.</p></abstract>
        <draft>draft-ietf-nfsv4-layout-types-13</draft>
        <updates>
            <doc-id>RFC5661</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8434</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8435</doc-id>
        <title>Parallel NFS (pNFS) Flexible File Layout</title>
        <author>
            <name>B. Halevy</name>
        </author>
        <author>
            <name>T. Haynes</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file.  The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols.  Client-side mirroring is also added to provide replication of files.</p></abstract>
        <draft>draft-ietf-nfsv4-flex-files-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8435</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8436</doc-id>
        <title>Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Diffserv</kw>
            <kw>DSCP</kw>
        </keywords>
        <abstract><p>The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.</p><p> This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.</p></abstract>
        <draft>draft-ietf-tsvwg-iana-dscp-registry-08</draft>
        <updates>
            <doc-id>RFC2474</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8436</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8437</doc-id>
        <title>IMAP UNAUTHENTICATE Extension for Connection Reuse</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>unauthenticate</kw>
            <kw>SASL</kw>
            <kw>login</kw>
            <kw>authenticate</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract><p>This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.</p></abstract>
        <draft>draft-ietf-extra-imap-unauth-01</draft>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8437</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8438</doc-id>
        <title>IMAP Extension for STATUS=SIZE</title>
        <author>
            <name>S. Bosch</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>imap</kw>
            <kw>status</kw>
            <kw>size</kw>
        </keywords>
        <abstract><p>This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP).  It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.</p></abstract>
        <draft>draft-ietf-extra-imap-status-size-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8438</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8439</doc-id>
        <title>ChaCha20 and Poly1305 for IETF Protocols</title>
        <author>
            <name>Y. Nir</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <date>
            <month>June</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>CHACHA</kw>
            <kw>CHACHA20</kw>
            <kw>POLY1305</kw>
            <kw>AEAD</kw>
        </keywords>
        <abstract><p>This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</p><p> RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.</p></abstract>
        <draft>draft-nir-cfrg-rfc7539bis-04</draft>
        <obsoletes>
            <doc-id>RFC7539</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8439</errata-url>
        <doi>10.17487/RFC8439</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8440</doc-id>
        <title>IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <author>
            <name>B. Gondwana</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IMAP4</kw>
            <kw>LIST</kw>
            <kw>MYRIGHTS</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.</p></abstract>
        <draft>draft-ietf-extra-imap-list-myrights-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8440</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8441</doc-id>
        <title>Bootstrapping WebSockets with HTTP/2</title>
        <author>
            <name>P. McManus</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>CONNECT SETTINGS</kw>
        </keywords>
        <abstract><p>This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.</p></abstract>
        <draft>draft-ietf-httpbis-h2-websockets-07</draft>
        <updates>
            <doc-id>RFC6455</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8441</errata-url>
        <doi>10.17487/RFC8441</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8442</doc-id>
        <title>ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2</title>
        <author>
            <name>J. Mattsson</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection.</p></abstract>
        <draft>draft-ietf-tls-ecdhe-psk-aead-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC8442</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8443</doc-id>
        <title>Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization</title>
        <author>
            <name>R. Singh</name>
        </author>
        <author>
            <name>M. Dolly</name>
        </author>
        <author>
            <name>S. Das</name>
        </author>
        <author>
            <name>A. Nguyen</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SIP Resource-Priority</kw>
            <kw>Resource Priority Header (rph)</kw>
            <kw>JSON Web Token Claim</kw>
            <kw>Identity header</kw>
            <kw>Authentication Service</kw>
            <kw>Assertion</kw>
            <kw>Verification Service</kw>
        </keywords>
        <abstract><p>This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.</p></abstract>
        <draft>draft-ietf-stir-rph-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC8443</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8444</doc-id>
        <title>OSPFv2 Extensions for Bit Index Explicit Replication (BIER)</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Kumar</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>A. Dolganow</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.</p><p> This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.</p></abstract>
        <draft>draft-ietf-bier-ospf-bier-extensions-18</draft>
        <updated-by>
            <doc-id>RFC9272</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <doi>10.17487/RFC8444</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8445</doc-id>
        <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
        <author>
            <name>A. Keranen</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>NAT</kw>
        </keywords>
        <abstract><p>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</p><p> This document obsoletes RFC 5245.</p></abstract>
        <draft>draft-ietf-ice-rfc5245bis-20</draft>
        <obsoletes>
            <doc-id>RFC5245</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8863</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ice</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8445</errata-url>
        <doi>10.17487/RFC8445</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8446</doc-id>
        <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>160</page-count>
        <keywords>
            <kw>international data algorithm</kw>
            <kw>symmetric</kw>
            <kw>transport protocol layer</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</p><p> This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</p></abstract>
        <draft>draft-ietf-tls-tls13-28</draft>
        <obsoletes>
            <doc-id>RFC5077</doc-id>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC6961</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5705</doc-id>
            <doc-id>RFC6066</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8446</errata-url>
        <doi>10.17487/RFC8446</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8447</doc-id>
        <title>IANA Registry Updates for TLS and DTLS</title>
        <author>
            <name>J. Salowey</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</p><p> This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</p></abstract>
        <draft>draft-ietf-tls-iana-registry-updates-05</draft>
        <updates>
            <doc-id>RFC3749</doc-id>
            <doc-id>RFC4680</doc-id>
            <doc-id>RFC5077</doc-id>
            <doc-id>RFC5246</doc-id>
            <doc-id>RFC5705</doc-id>
            <doc-id>RFC5878</doc-id>
            <doc-id>RFC6520</doc-id>
            <doc-id>RFC7301</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8447</errata-url>
        <doi>10.17487/RFC8447</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8448</doc-id>
        <title>Example Handshake Traces for TLS 1.3</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>68</page-count>
        <abstract><p>This document includes examples of TLS 1.3 handshakes.  Private keys and inputs are provided so that these handshakes might be reproduced.  Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.</p></abstract>
        <draft>draft-ietf-tls-tls13-vectors-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8448</errata-url>
        <doi>10.17487/RFC8448</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8449</doc-id>
        <title>Record Size Limit Extension for TLS</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>record</kw>
            <kw>IoT</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.</p><p> This replaces the maximum fragment length extension defined in RFC 6066.</p></abstract>
        <draft>draft-ietf-tls-record-limit-03</draft>
        <updates>
            <doc-id>RFC6066</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC8449</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8450</doc-id>
        <title>RTP Payload Format for VC-2 High Quality (HQ) Profile</title>
        <author>
            <name>J. Weaver</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>rtp</kw>
            <kw>vc-2</kw>
            <kw>VC2</kw>
            <kw>dirac</kw>
        </keywords>
        <abstract><p>This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.</p><p> The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).</p></abstract>
        <draft>draft-ietf-payload-rtp-vc2hq-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <doi>10.17487/RFC8450</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8451</doc-id>
        <title>Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API</title>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>R. Huang</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>L. Deng</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Web real-time communication</kw>
        </keywords>
        <abstract><p>This document describes monitoring features related to media streams in Web real-time communication (WebRTC).  It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments.  It lists a set of identifiers for the WebRTC's statistics API.  These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.</p></abstract>
        <draft>draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>xrblock</wg_acronym>
        <doi>10.17487/RFC8451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8452</doc-id>
        <title>AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption</title>
        <author>
            <name>S. Gueron</name>
        </author>
        <author>
            <name>A. Langley</name>
        </author>
        <author>
            <name>Y. Lindell</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>authenticated encryption</kw>
            <kw>aead</kw>
            <kw>aes</kw>
            <kw>gcm</kw>
            <kw>siv</kw>
        </keywords>
        <abstract><p>This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.</p><p> This document is the product of the Crypto Forum Research Group.</p></abstract>
        <draft>draft-irtf-cfrg-gcmsiv-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8452</errata-url>
        <doi>10.17487/RFC8452</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8453</doc-id>
        <title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
        <author>
            <name>D. Ceccarelli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>SDN</kw>
            <kw>Orchestration</kw>
        </keywords>
        <abstract><p>Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</p><p> Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</p><p> This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</p></abstract>
        <draft>draft-ietf-teas-actn-framework-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8453</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8454</doc-id>
        <title>Information Model for Abstraction and Control of TE Networks (ACTN)</title>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>S. Belotti</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>B. Yoon</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document provides an information model for Abstraction and Control of TE Networks (ACTN).</p></abstract>
        <draft>draft-ietf-teas-actn-info-model-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8454</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8455</doc-id>
        <title>Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance</title>
        <author>
            <name>V. Bhuvaneswaran</name>
        </author>
        <author>
            <name>A. Basil</name>
        </author>
        <author>
            <name>M. Tassinari</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>S. Banks</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance.  It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers.  The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.</p></abstract>
        <draft>draft-ietf-bmwg-sdn-controller-benchmark-term-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8455</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8456</doc-id>
        <title>Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance</title>
        <author>
            <name>V. Bhuvaneswaran</name>
        </author>
        <author>
            <name>A. Basil</name>
        </author>
        <author>
            <name>M. Tassinari</name>
        </author>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>S. Banks</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers.  The SDN Controller is a core component in the SDN architecture that controls the behavior of the network.  SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality.  Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers.  This document provides a method for measuring the performance of all controller implementations.</p></abstract>
        <draft>draft-ietf-bmwg-sdn-controller-benchmark-meth-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC8456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8457</doc-id>
        <title>IMAP "$Important" Keyword and "\Important" Special-Use Attribute</title>
        <author>
            <name>B. Leiba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IMAP attributes</kw>
        </keywords>
        <abstract><p>RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes.  This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154.  This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.</p></abstract>
        <draft>draft-ietf-extra-specialuse-important-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8457</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8458</doc-id>
        <title>Using National Bibliography Numbers as Uniform Resource Names</title>
        <author>
            <name>J. Hakala</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Network Working Group</kw>
            <kw>National bibliography numbers</kw>
            <kw>Uniform resource names</kw>
        </keywords>
        <abstract><p>National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as International Standard Book Number (ISBN).</p><p> A Uniform Resource Name (URN) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.</p><p> This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.</p></abstract>
        <draft>draft-hakala-urn-nbn-rfc3188bis-02</draft>
        <obsoletes>
            <doc-id>RFC3188</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8459</doc-id>
        <title>Hierarchical Service Function Chaining (hSFC)</title>
        <author>
            <name>D. Dolson</name>
        </author>
        <author>
            <name>S. Homma</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Scalability</kw>
            <kw>SFC-enabled domain</kw>
            <kw>multiple control domains</kw>
            <kw>SFC complexity</kw>
            <kw>Hierarchy</kw>
            <kw>service delivery</kw>
            <kw>service complications</kw>
            <kw>service offering</kw>
            <kw>differentiated services</kw>
            <kw>large scale network</kw>
        </keywords>
        <abstract><p>Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.</p><p> The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.</p></abstract>
        <draft>draft-ietf-sfc-hierarchical-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC8459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8460</doc-id>
        <title>SMTP TLS Reporting</title>
        <author>
            <name>D. Margolis</name>
        </author>
        <author>
            <name>A. Brotman</name>
        </author>
        <author>
            <name>B. Ramakrishnan</name>
        </author>
        <author>
            <name>J. Jones</name>
        </author>
        <author>
            <name>M. Risher</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>DANE</kw>
            <kw>MTA-STS</kw>
        </keywords>
        <abstract><p>A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS).  These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels.  This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains.  Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.</p></abstract>
        <draft>draft-ietf-uta-smtp-tlsrpt-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8460</errata-url>
        <doi>10.17487/RFC8460</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8461</doc-id>
        <title>SMTP MTA Strict Transport Security (MTA-STS)</title>
        <author>
            <name>D. Margolis</name>
        </author>
        <author>
            <name>M. Risher</name>
        </author>
        <author>
            <name>B. Ramakrishnan</name>
        </author>
        <author>
            <name>A. Brotman</name>
        </author>
        <author>
            <name>J. Jones</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>SMTP STARTTLS</kw>
            <kw>Mail Security</kw>
        </keywords>
        <abstract><p>SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.</p></abstract>
        <draft>draft-ietf-uta-mta-sts-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8461</errata-url>
        <doi>10.17487/RFC8461</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8462</doc-id>
        <title>Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)</title>
        <author>
            <name>N. Rooney</name>
        </author>
        <author>
            <name>S. Dawkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Networks</kw>
        </keywords>
        <abstract><p>The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.</p><p> The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.</p><p> A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.</p></abstract>
        <draft>draft-iab-marnew-report-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8462</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8463</doc-id>
        <title>A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)</title>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>ed25519</kw>
            <kw>cryptography</kw>
        </keywords>
        <abstract><p>This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376).  DKIM verifiers are required to implement this algorithm.</p></abstract>
        <draft>draft-ietf-dcrup-dkim-crypto-14</draft>
        <updates>
            <doc-id>RFC6376</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dcrup</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8463</errata-url>
        <doi>10.17487/RFC8463</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8464</doc-id>
        <title>A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)</title>
        <author>
            <name>R. Atarius</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>MEID</kw>
            <kw>instance ID</kw>
            <kw>IMS</kw>
        </keywords>
        <abstract><p>This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID).  The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone).  The 3GPP2 has a requirement to be able to use an MEID as a URN.  This document fulfills that requirement.</p></abstract>
        <draft>draft-atarius-dispatch-meid-urn-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8464</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8465</doc-id>
        <title>Using the Mobile Equipment Identity (MEID) URN as an Instance ID</title>
        <author>
            <name>R. Atarius</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MEID</kw>
            <kw>instance ID</kw>
            <kw>IMS</kw>
        </keywords>
        <abstract><p>This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an Instance ID.  The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.</p></abstract>
        <draft>draft-atarius-dispatch-meid-urn-as-instanceid-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8465</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8466</doc-id>
        <title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery</title>
        <author>
            <name>B. Wen</name>
        </author>
        <author>
            <name>G. Fioccola</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Xie</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>158</page-count>
        <keywords>
            <kw>L2SM</kw>
            <kw>Service Model</kw>
            <kw>L2VPN SM</kw>
            <kw>L2VPN Service Model</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.</p><p> The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.</p><p> The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</p></abstract>
        <draft>draft-ietf-l2sm-l2vpn-service-model-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>l2sm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8466</errata-url>
        <doi>10.17487/RFC8466</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8467</doc-id>
        <title>Padding Policies for Extension Mechanisms for DNS (EDNS(0))</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>security</kw>
        </keywords>
        <abstract><p>RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications.  This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.</p></abstract>
        <draft>draft-ietf-dprive-padding-policy-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8467</errata-url>
        <doi>10.17487/RFC8467</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8468</doc-id>
        <title>IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>J. Fabini</name>
        </author>
        <author>
            <name>N. Elkins</name>
        </author>
        <author>
            <name>M. Ackermann</name>
        </author>
        <author>
            <name>V. Hegde</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Measurement</kw>
            <kw>Methodology</kw>
            <kw>Standard-Formed Packet</kw>
            <kw>Type-P</kw>
            <kw>Minimal Packet</kw>
            <kw>IPv6 Transition</kw>
        </keywords>
        <abstract><p>This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing.  It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330.  This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework.  Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation.  IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation.</p></abstract>
        <draft>draft-ietf-ippm-2330-ipv6-06</draft>
        <updates>
            <doc-id>RFC2330</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8468</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8469</doc-id>
        <title>Recommendation to Use the Ethernet Control Word</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>I. Bagdonas</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>pseudowire</kw>
            <kw>PW</kw>
            <kw>CW</kw>
            <kw>ECMP</kw>
            <kw>MAC address</kw>
            <kw>out of order</kw>
            <kw>ordering</kw>
        </keywords>
        <abstract><p>The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.</p><p> This document updates RFC 4448.</p></abstract>
        <draft>draft-ietf-pals-ethernet-cw-07</draft>
        <updates>
            <doc-id>RFC4448</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8469</errata-url>
        <doi>10.17487/RFC8469</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8470</doc-id>
        <title>Using Early Data in HTTP</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>W. Tarreau</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>TLS</kw>
            <kw>replay</kw>
            <kw>retry</kw>
            <kw>0-RTT</kw>
            <kw>early data</kw>
            <kw>status code</kw>
        </keywords>
        <abstract><p>Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay.</p></abstract>
        <draft>draft-ietf-httpbis-replay-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8470</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8471</doc-id>
        <title>The Token Binding Protocol Version 1.0</title>
        <author>
            <name>A. Popov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nystroem</name>
        </author>
        <author>
            <name>D. Balfanz</name>
        </author>
        <author>
            <name>J. Hodges</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Token</kw>
            <kw>cookie</kw>
            <kw>TLS</kw>
            <kw>export</kw>
            <kw>replay</kw>
        </keywords>
        <abstract><p>This document specifies version 1.0 of the Token Binding protocol.  The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections.  Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks.  To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.</p></abstract>
        <draft>draft-ietf-tokbind-protocol-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tokbind</wg_acronym>
        <doi>10.17487/RFC8471</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8472</doc-id>
        <title>Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation</title>
        <author>
            <name>A. Popov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nystroem</name>
        </author>
        <author>
            <name>D. Balfanz</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Cookie</kw>
            <kw>TLS</kw>
            <kw>export</kw>
            <kw>replay</kw>
        </keywords>
        <abstract><p>This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters.  Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.</p></abstract>
        <draft>draft-ietf-tokbind-negotiation-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tokbind</wg_acronym>
        <doi>10.17487/RFC8472</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8473</doc-id>
        <title>Token Binding over HTTP</title>
        <author>
            <name>A. Popov</name>
        </author>
        <author>
            <name>M. Nystroem</name>
        </author>
        <author>
            <name>D. Balfanz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Harper</name>
        </author>
        <author>
            <name>J. Hodges</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Cookie</kw>
            <kw>TLS</kw>
            <kw>OAuth</kw>
            <kw>export</kw>
            <kw>replay</kw>
        </keywords>
        <abstract><p>This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.</p><p> We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.</p><p> Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.</p><p> This document is a companion document to "The Token Binding Protocol Version 1.0" (RFC 8471).</p></abstract>
        <draft>draft-ietf-tokbind-https-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tokbind</wg_acronym>
        <doi>10.17487/RFC8473</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8474</doc-id>
        <title>IMAP Extension for Object Identifiers</title>
        <author>
            <name>B. Gondwana</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.</p></abstract>
        <draft>draft-ietf-extra-imap-objectid-08</draft>
        <updates>
            <doc-id>RFC3501</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8475</doc-id>
        <title>Using Conditional Router Advertisements for Enterprise Multihoming</title>
        <author>
            <name>J. Linkova</name>
        </author>
        <author>
            <name>M. Stucchi</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>ipv6</kw>
        </keywords>
        <abstract><p>This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios.  The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic.  The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue.  It also proposes using Router Advertisements to influence the host source address selection.  It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases.  In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.</p></abstract>
        <draft>draft-ietf-v6ops-conditional-ras-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8475</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8476</doc-id>
        <title>Signaling Maximum SID Depth (MSD) Using OSPF</title>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>U. Chunduri</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>SID</kw>
            <kw>MSD</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.  Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.  This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types.  Here, the term "OSPF" means both OSPFv2 and OSPFv3.</p></abstract>
        <draft>draft-ietf-ospf-segment-routing-msd-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8476</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8477</doc-id>
        <title>Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016</title>
        <author>
            <name>J. Jimenez</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>data model</kw>
        </keywords>
        <abstract><p>This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016.  The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer.  This report summarizes the discussions and lists recommendations to the standards community.  The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop.  Note that this document is a report on the proceedings of the workshop.  The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-iotsi-workshop-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8477</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8478</doc-id>
        <title>Zstandard Compression and the application/zstd Media Type</title>
        <author>
            <name>Y. Collet</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>Compression</kw>
        </keywords>
        <abstract><p>Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME).</p><p> Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.</p></abstract>
        <draft>draft-kucherawy-dispatch-zstd-03</draft>
        <obsoleted-by>
            <doc-id>RFC8878</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8478</errata-url>
        <doi>10.17487/RFC8478</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8479</doc-id>
        <title>Storing Validation Parameters in PKCS#8</title>
        <author>
            <name>N. Mavrogiannopoulos</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>private keys</kw>
            <kw>validation parameters</kw>
            <kw>PKCS#8</kw>
        </keywords>
        <abstract><p>This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information Syntax Specification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-Key Information Syntax Specification as defined in RFC 5958.</p><p> The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.</p></abstract>
        <draft>draft-mavrogiannopoulos-pkcs8-validated-parameters-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8479</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8480</doc-id>
        <title>6TiSCH Operation Sublayer (6top) Protocol (6P)</title>
        <author>
            <name>Q. Wang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Vilajosana</name>
        </author>
        <author>
            <name>T. Watteyne</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>schedule management</kw>
            <kw>distributed scheduling</kw>
            <kw>time synchronized channel hopping scheduling</kw>
        </keywords>
        <abstract><p>This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another.  6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer.  6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document.  A 6top SF decides when to add/delete cells, and it triggers 6P Transactions.  The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.</p></abstract>
        <draft>draft-ietf-6tisch-6top-protocol-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <doi>10.17487/RFC8480</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8481</doc-id>
        <title>Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>September</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>security</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration.  This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.</p></abstract>
        <draft>draft-ietf-sidrops-ov-clarify-05</draft>
        <updates>
            <doc-id>RFC6811</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9324</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8481</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8482</doc-id>
        <title>Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>M. Majkowski</name>
        </author>
        <author>
            <name>E. Hunt</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>ANY</kw>
            <kw>REFUSE</kw>
            <kw>DDOS</kw>
            <kw>ABUSE</kw>
        </keywords>
        <abstract><p>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.</p><p> The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.</p><p> This document updates RFCs 1034 and 1035.</p></abstract>
        <draft>draft-ietf-dnsop-refuse-any-07</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8483</doc-id>
        <title>Yeti DNS Testbed</title>
        <author>
            <name>L. Song</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Liu</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <author>
            <name>A. Kato</name>
        </author>
        <author>
            <name>S. Kerr</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>Root Server</kw>
            <kw>DNSSEC</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure.  This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet's Domain Name System is designed and built).</p></abstract>
        <draft>draft-song-yeti-testbed-experience-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8483</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8484</doc-id>
        <title>DNS Queries over HTTPS (DoH)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>P. McManus</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>HTTP</kw>
            <kw>DoH</kw>
        </keywords>
        <abstract><p>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</p></abstract>
        <draft>draft-ietf-doh-dns-over-https-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>doh</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8484</errata-url>
        <doi>10.17487/RFC8484</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8485</doc-id>
        <title>Vectors of Trust</title>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Johansson</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants.  These aspects are used to determine the amount of trust to be placed in that transaction.</p></abstract>
        <draft>draft-richer-vectors-of-trust-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8485</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8486</doc-id>
        <title>Ambisonics in an Ogg Opus Container</title>
        <author>
            <name>J. Skoglund</name>
        </author>
        <author>
            <name>M. Graczyk</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>spatial audio</kw>
            <kw>lossy compression</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format.  It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.</p></abstract>
        <draft>draft-ietf-codec-ambisonics-10</draft>
        <updates>
            <doc-id>RFC7845</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>codec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8486</errata-url>
        <doi>10.17487/RFC8486</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8487</doc-id>
        <title>Mtrace Version 2: Traceroute Facility for IP Multicast</title>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>K. Meyer</name>
        </author>
        <author>
            <name>W. Lee</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>mtrace</kw>
            <kw>mtrace2</kw>
            <kw>traceroute</kw>
            <kw>PIM</kw>
        </keywords>
        <abstract><p>This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2).  Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers.  This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.</p></abstract>
        <draft>draft-ietf-mboned-mtrace-v2-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC8487</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8488</doc-id>
        <title>RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation</title>
        <author>
            <name>O. Muravskiy</name>
        </author>
        <author>
            <name>T. Bruijnzeels</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>validation</kw>
            <kw>RRDP</kw>
        </keywords>
        <abstract><p>This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator.  This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.</p></abstract>
        <draft>draft-ietf-sidrops-rpki-tree-validation-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8488</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8489</doc-id>
        <title>Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>67</page-count>
        <keywords>
            <kw>SIPs</kw>
        </keywords>
        <abstract><p>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs and does not require any special behavior from them.</p><p> STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution.</p><p> This document obsoletes RFC 5389.</p></abstract>
        <draft>draft-ietf-tram-stunbis-21</draft>
        <obsoletes>
            <doc-id>RFC5389</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8489</errata-url>
        <doi>10.17487/RFC8489</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8490</doc-id>
        <title>DNS Stateful Operations</title>
        <author>
            <name>R. Bellis</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>J. Dickinson</name>
        </author>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>T. Pusateri</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>This document defines a new DNS OPCODE for DNS Stateful Operations (DSO).  DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax.  Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations.  This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code.  This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.</p></abstract>
        <draft>draft-ietf-dnsop-session-signal-20</draft>
        <updates>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC7766</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8490</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8491</doc-id>
        <title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>U. Chunduri</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>SID</kw>
            <kw>MSD</kw>
            <kw>IS-IS</kw>
        </keywords>
        <abstract><p>This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.  Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network.  This document only defines one type of MSD: Base MPLS Imposition.  However, it defines an encoding that can support other MSD types.  This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.</p></abstract>
        <draft>draft-ietf-isis-segment-routing-msd-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8491</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8492</doc-id>
        <title>Secure Password Ciphersuites for Transport Layer Security (TLS)</title>
        <author>
            <name>D. Harkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Password Authenticated Key Exchange</kw>
            <kw>Dictionary Attack</kw>
            <kw>Authentication</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password.  The exchange is called "TLS-PWD".  The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.</p></abstract>
        <draft>draft-harkins-tls-dragonfly-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8492</errata-url>
        <doi>10.17487/RFC8492</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8493</doc-id>
        <title>The BagIt File Packaging Format (V1.0)</title>
        <author>
            <name>J. Kunze</name>
        </author>
        <author>
            <name>J. Littman</name>
        </author>
        <author>
            <name>E. Madden</name>
        </author>
        <author>
            <name>J. Scancella</name>
        </author>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content.  A "bag" has just enough structure to enclose descriptive metadata "tags" and a file "payload" but does not require knowledge of the payload's internal semantics.  This BagIt format is suitable for reliable storage and transfer.</p></abstract>
        <draft>draft-kunze-bagit-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8493</errata-url>
        <doi>10.17487/RFC8493</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8494</doc-id>
        <title>Multicast Email (MULE) over Allied Communications Publication (ACP) 142</title>
        <author>
            <name>D. Wilson</name>
        </author>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>P_MUL</kw>
        </keywords>
        <abstract><p>Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).</p><p> This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.</p><p> This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.</p></abstract>
        <draft>draft-melnikov-email-over-pmul-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8494</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8495</doc-id>
        <title>Allocation Token Extension for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>K. Feher</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands.  The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".</p></abstract>
        <draft>draft-ietf-regext-allocation-token-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8495</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8496</doc-id>
        <title>P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)</title>
        <author>
            <name>D. York</name>
        </author>
        <author>
            <name>T. Asveren</name>
        </author>
        <date>
            <month>October</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>p-header</kw>
        </keywords>
        <abstract><p>This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged.  This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007.  This document details the registration of this header field with IANA.</p></abstract>
        <draft>draft-york-p-charge-info-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8496</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8497</doc-id>
        <title>Marking SIP Messages to Be Logged</title>
        <author>
            <name>P. Dawes</name>
        </author>
        <author>
            <name>C. Arunachalam</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>logme</kw>
            <kw>troubleshooting</kw>
            <kw>debug</kw>
            <kw>debugging</kw>
            <kw>logging</kw>
        </keywords>
        <abstract><p>SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.</p><p> This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.</p></abstract>
        <draft>draft-ietf-insipid-logme-marking-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>insipid</wg_acronym>
        <doi>10.17487/RFC8497</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8498</doc-id>
        <title>A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>M. Mohali</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>RFC5502</kw>
            <kw>P-</kw>
            <kw>3GPP</kw>
            <kw>IMS</kw>
            <kw>Served-User</kw>
            <kw>orig-cdiv</kw>
        </keywords>
        <abstract><p>The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation.  A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user.  This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv".  The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user.  This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.</p></abstract>
        <draft>draft-ietf-sipcore-originating-cdiv-parameter-08</draft>
        <updates>
            <doc-id>RFC5502</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8498</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8499</doc-id>
        <title>DNS Terminology</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>A. Sullivan</name>
        </author>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>vocabulary</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</p><p> This document obsoletes RFC 7719 and updates RFC 2308.</p></abstract>
        <draft>draft-ietf-dnsop-terminology-bis-14</draft>
        <obsoletes>
            <doc-id>RFC7719</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9499</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2308</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8499</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8500</doc-id>
        <title>IS-IS Routing with Reverse Metric</title>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>S. Amante</name>
        </author>
        <author>
            <name>M. Abrahamsson</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>IS-IS</kw>
            <kw>Metric</kw>
            <kw>Reverse-Metric</kw>
            <kw>IIH</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events.  This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router.</p></abstract>
        <draft>draft-ietf-isis-reverse-metric-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8500</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8501</doc-id>
        <title>Reverse DNS in IPv6 for Internet Service Providers</title>
        <author>
            <name>L. Howard</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>PTR</kw>
            <kw>rDNS</kw>
            <kw>Reverse DNS</kw>
        </keywords>
        <abstract><p>In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address.  This practice does not scale in IPv6.  This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.</p></abstract>
        <draft>draft-ietf-dnsop-isp-ip6rdns-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8501</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8502</doc-id>
        <title>L2L3 VPN Multicast MIB</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>H. Tsunoda</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MVPN</kw>
            <kw>BGP</kw>
            <kw>MPLS</kw>
            <kw>P-tunnel</kw>
            <kw>PMSI Tunnel attribute</kw>
            <kw>SNMP</kw>
            <kw>monitor</kw>
            <kw> management</kw>
        </keywords>
        <abstract><p>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 two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.</p></abstract>
        <draft>draft-ietf-bess-l2l3-vpn-mcast-mib-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8502</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8503</doc-id>
        <title>BGP/MPLS Layer 3 VPN Multicast Management Information Base</title>
        <author>
            <name>H. Tsunoda</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>MVPN</kw>
            <kw>PE router</kw>
            <kw>P-tunnel</kw>
            <kw>PMSI</kw>
            <kw>MIB</kw>
            <kw>SNMP</kw>
            <kw>monitor</kw>
        </keywords>
        <abstract><p>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 to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by the Multiprotocol Label Switching/Border Gateway Protocol (MPLS/BGP) on a Provider Edge (PE) router.</p></abstract>
        <draft>draft-ietf-bess-mvpn-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8503</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8504</doc-id>
        <title>IPv6 Node Requirements</title>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>T. Winters</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Internet Protocol Version 6</kw>
            <kw>Internet Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.</p><p> This document obsoletes RFC 6434, and in turn RFC 4294.</p></abstract>
        <draft>draft-ietf-6man-rfc6434-bis-09</draft>
        <obsoletes>
            <doc-id>RFC6434</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0220</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8504</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8505</doc-id>
        <title>Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>Wi-Fi</kw>
        </keywords>
        <abstract><p>This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.</p></abstract>
        <draft>draft-ietf-6lo-rfc6775-update-21</draft>
        <updates>
            <doc-id>RFC6775</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC8928</doc-id>
            <doc-id>RFC8929</doc-id>
            <doc-id>RFC9010</doc-id>
            <doc-id>RFC9685</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8505</errata-url>
        <doi>10.17487/RFC8505</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8506</doc-id>
        <title>Diameter Credit-Control Application</title>
        <author>
            <name>L. Bertz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Dolson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Lifshitz</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>130</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>charging</kw>
        </keywords>
        <abstract><p>This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.  The Diameter Credit- Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations.</p></abstract>
        <draft>draft-ietf-dime-rfc4006bis-12</draft>
        <obsoletes>
            <doc-id>RFC4006</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC8506</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8507</doc-id>
        <title>Simple Internet Protocol (SIP) Specification</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>R. Hinden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract><p>This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6.</p><p> The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.</p><p> The paragraph that follows is the Abstract from the original draft.</p><p> This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.</p></abstract>
        <draft>draft-historic-simple-ip-03</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8507</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8508</doc-id>
        <title>IMAP REPLACE Extension</title>
        <author>
            <name>S. Brandt</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message.  Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.</p></abstract>
        <draft>draft-ietf-extra-imap-replace-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8508</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8509</doc-id>
        <title>A Root Key Trust Anchor Sentinel for DNSSEC</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>J. Damas</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>KSK</kw>
            <kw>RFC5011</kw>
            <kw>DNS</kw>
            <kw>rollover</kw>
            <kw>root-key-sentinel-is-ta-</kw>
            <kw>root-key-sentinel-not-ta-</kw>
            <kw>root key</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries.  Note that this method is only applicable for determining which keys are in the trust store for the root key.</p></abstract>
        <draft>draft-ietf-dnsop-kskroll-sentinel-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8509</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8510</doc-id>
        <title>OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).</p><p> This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.</p></abstract>
        <draft>draft-ietf-ospf-lls-interface-id-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8510</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8511</doc-id>
        <title>TCP Alternative Backoff with ECN (ABE)</title>
        <author>
            <name>N. Khademi</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>G. Armitage</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>December</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck.  This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large.  The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short.  Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss.  Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.</p></abstract>
        <draft>draft-ietf-tcpm-alternativebackoff-ecn-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC8511</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8512</doc-id>
        <title>A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>S. Vinapamula</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <keywords>
            <kw>address sharing</kw>
            <kw>address depletion</kw>
            <kw>IPv4 service continuity</kw>
            <kw>NETCONF</kw>
            <kw>programmability</kw>
            <kw>automation</kw>
            <kw>service automation</kw>
            <kw>NPTv6</kw>
            <kw>SIIT</kw>
            <kw>NAT64</kw>
            <kw>CLAT</kw>
            <kw>Destination NAT</kw>
            <kw>Port Restricted NAT</kw>
            <kw>Port Range</kw>
        </keywords>
        <abstract><p>This document defines a YANG module for the Network Address Translation (NAT) function.</p><p> Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document.</p></abstract>
        <draft>draft-ietf-opsawg-nat-yang-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC8512</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8513</doc-id>
        <title>A YANG Data Model for Dual-Stack Lite (DS-Lite)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>S. Sivakumar</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IPv4 service continuity</kw>
            <kw>IPv4 address exhaustion</kw>
            <kw>Service Availability</kw>
            <kw>Address sharing</kw>
            <kw>IPv6</kw>
            <kw>Reliability</kw>
            <kw>IPv4 over IPv6</kw>
        </keywords>
        <abstract><p>This document defines a YANG module for the Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.</p></abstract>
        <draft>draft-ietf-softwire-dslite-yang-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8514</doc-id>
        <title>Internet Message Access Protocol (IMAP) - SAVEDATE Extension</title>
        <author>
            <name>S. Bosch</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>imap</kw>
            <kw>savedate</kw>
        </keywords>
        <abstract><p>This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP).  It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox.  The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria.</p></abstract>
        <draft>draft-ietf-extra-imap-savedate-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8515</doc-id>
        <title>URN Namespace for ETSI Documents</title>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>M.A. Reina Ortega</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document describes the Namespace Identifier (NID) "etsi" for Uniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute (http://etsi.org).  ETSI specifies and manages resources that utilize this URN identification model.  Management activities for these and other resource types are handled by the manager of the ETSI Protocol Naming and Numbering Service (PNNS).</p></abstract>
        <draft>draft-mahesh-etsi-urn-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8516</doc-id>
        <title>"Too Many Requests" Response Code for the Constrained Application Protocol</title>
        <author>
            <name>A. Keranen</name>
        </author>
        <date>
            <month>January</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>CoAP</kw>
        </keywords>
        <abstract><p>A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle.  This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests.</p></abstract>
        <draft>draft-ietf-core-too-many-reqs-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8516</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8517</doc-id>
        <title>An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective</title>
        <author>
            <name>D. Dolson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Snellman</name>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>address sharing</kw>
            <kw>NAT</kw>
            <kw>firewall</kw>
            <kw>Service Function</kw>
            <kw>transport</kw>
            <kw>service delivery</kw>
            <kw>Internet architecture</kw>
            <kw>TCP QUIC</kw>
            <kw>Path Layer UDP Substrate</kw>
        </keywords>
        <abstract><p>This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".</p><p> RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.</p></abstract>
        <draft>draft-dolson-transport-middlebox-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8517</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8518</doc-id>
        <title>Selection of Loop-Free Alternates for Multi-Homed Prefixes</title>
        <author>
            <name>P. Sarkar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>U. Chunduri</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>LFA</kw>
            <kw>Multi-homed Prefix</kw>
            <kw>IGP</kw>
        </keywords>
        <abstract><p>Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement.  This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs.  It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs.  This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.</p></abstract>
        <draft>draft-ietf-rtgwg-multihomed-prefix-lfa-09</draft>
        <updates>
            <doc-id>RFC5286</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8519</doc-id>
        <title>YANG Data Model for Network Access Control Lists (ACLs)</title>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>S. Agarwal</name>
        </author>
        <author>
            <name>L. Huang</name>
        </author>
        <author>
            <name>D. Blair</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>ACE</kw>
            <kw>ACL</kw>
            <kw>Firewall</kw>
            <kw>PBR</kw>
            <kw>NMDA</kw>
        </keywords>
        <abstract><p>This document defines a data model for Access Control Lists (ACLs).  An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device.  Each rule is used to find a match on a packet and define actions that will be performed on the packet.</p></abstract>
        <draft>draft-ietf-netmod-acl-model-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8519</errata-url>
        <doi>10.17487/RFC8519</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8520</doc-id>
        <title>Manufacturer Usage Description Specification</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>MUD</kw>
            <kw>IoT Security</kw>
            <kw>Access Policy</kw>
        </keywords>
        <abstract><p>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.</p><p> This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</p></abstract>
        <draft>draft-ietf-opsawg-mud-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8520</errata-url>
        <doi>10.17487/RFC8520</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8521</doc-id>
        <title>Registration Data Access Protocol (RDAP) Object Tagging</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>November</month>
            <year>2018</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>Entity</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract><p>The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries.  The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries.  This limitation exists because the identifiers associated with these query types are typically unstructured.  This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries.</p></abstract>
        <draft>draft-ietf-regext-rdap-object-tag-05</draft>
        <updates>
            <doc-id>RFC7484</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0221</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8521</errata-url>
        <doi>10.17487/RFC8521</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8522</doc-id>
        <title>Looking Glass Command Set</title>
        <author>
            <name>M. Stubbig</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Looking Glass</kw>
        </keywords>
        <abstract><p>This document introduces a command set standard to the web-based "Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.</p><p> The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format.</p></abstract>
        <draft>draft-mst-lgapi-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8522</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8523</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8524</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8525</doc-id>
        <title>YANG Library</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>R. Wilton</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>NMDA</kw>
        </keywords>
        <abstract><p>This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server.  Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.  This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.</p></abstract>
        <draft>draft-ietf-netconf-rfc7895bis-07</draft>
        <obsoletes>
            <doc-id>RFC7895</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8525</errata-url>
        <doi>10.17487/RFC8525</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8526</doc-id>
        <title>NETCONF Extensions to Support the Network Management Datastore Architecture</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>P. Shafer</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>R. Wilton</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>NMDA</kw>
        </keywords>
        <abstract><p>This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p><p> This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new &lt;get-data&gt; and &lt;edit-data&gt; operations and augments existing &lt;lock&gt;, &lt;unlock&gt;, and &lt;validate&gt; operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA.</p></abstract>
        <draft>draft-ietf-netconf-nmda-netconf-08</draft>
        <updates>
            <doc-id>RFC6241</doc-id>
            <doc-id>RFC7950</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC8526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8527</doc-id>
        <title>RESTCONF Extensions to Support the Network Management Datastore Architecture</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>P. Shafer</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>R. Wilton</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p><p> This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA.</p></abstract>
        <draft>draft-ietf-netconf-nmda-restconf-05</draft>
        <updates>
            <doc-id>RFC8040</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC8527</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8528</doc-id>
        <title>YANG Schema Mount</title>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <author>
            <name>L. Lhotka</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module.</p></abstract>
        <draft>draft-ietf-netmod-schema-mount-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8528</errata-url>
        <doi>10.17487/RFC8528</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8529</doc-id>
        <title>YANG Data Model for Network Instances</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>C. Hopps</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>D. Bogdanovic</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>VRF</kw>
            <kw>VSI</kw>
            <kw>VPN</kw>
        </keywords>
        <abstract><p>This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).</p><p> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p></abstract>
        <draft>draft-ietf-rtgwg-ni-model-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8529</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8530</doc-id>
        <title>YANG Model for Logical Network Elements</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>C. Hopps</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>D. Bogdanovic</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>VRF</kw>
            <kw>VSI</kw>
            <kw>VPN</kw>
        </keywords>
        <abstract><p>This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA).  This module can be used to manage the logical resource partitioning that may be present on a network device.  Examples of common industry terms for logical resource partitioning are logical systems or logical routers.  The YANG model in this document conforms with NMDA as defined in RFC 8342.</p></abstract>
        <draft>draft-ietf-rtgwg-lne-model-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8530</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8531</doc-id>
        <title>Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols</title>
        <author>
            <name>D. Kumar</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>Z. Wang</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <abstract><p>This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).</p><p> The YANG data model in this document conforms to the Network Management Datastore Architecture.</p></abstract>
        <draft>draft-ietf-lime-yang-connection-oriented-oam-model-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8531</errata-url>
        <doi>10.17487/RFC8531</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8532</doc-id>
        <title>Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications</title>
        <author>
            <name>D. Kumar</name>
        </author>
        <author>
            <name>Z. Wang</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>S. Raghavan</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>59</page-count>
        <abstract><p>This document presents a base YANG Data model for the management of Operations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using the YANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.</p><p> There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same level through a unified interface).</p></abstract>
        <draft>draft-ietf-lime-yang-connectionless-oam-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lime</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8532</errata-url>
        <doi>10.17487/RFC8532</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8533</doc-id>
        <title>A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications</title>
        <author>
            <name>D. Kumar</name>
        </author>
        <author>
            <name>M. Wang</name>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>S. Raghavan</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>CL OAM Retrieval Methods</kw>
        </keywords>
        <abstract><p>This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols.  It provides technology-independent RPC operations for OAM protocols that use connectionless communication.  The retrieval methods model herein presented can be extended to include technology- specific details.  There are two key benefits of this approach: First, it leads to uniformity between OAM protocols.  Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface).</p></abstract>
        <draft>draft-ietf-lime-yang-connectionless-oam-methods-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>lime</wg_acronym>
        <doi>10.17487/RFC8533</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8534</doc-id>
        <title>Explicit Tracking with Wildcard Routes in Multicast VPN</title>
        <author>
            <name>A. Dolganow</name>
        </author>
        <author>
            <name>J. Kotalwar</name>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Multicast MVPN</kw>
        </keywords>
        <abstract><p>The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows.  However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios.  This document provides the necessary clarifications.  It also specifies a new, optimized explicit-tracking procedure.  This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism.  This document updates RFCs 6514, 6625, 7524, 7582, and 7900.</p></abstract>
        <draft>draft-ietf-bess-mvpn-expl-track-13</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
            <doc-id>RFC6625</doc-id>
            <doc-id>RFC7524</doc-id>
            <doc-id>RFC7582</doc-id>
            <doc-id>RFC7900</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8534</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8535</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8536</doc-id>
        <title>The Time Zone Information Format (TZif)</title>
        <author>
            <name>A. Olson</name>
        </author>
        <author>
            <name>P. Eggert</name>
        </author>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>time zone</kw>
            <kw>tzdata</kw>
            <kw>tzif</kw>
        </keywords>
        <abstract><p>This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol.  Two media types for this format are also defined.</p></abstract>
        <draft>draft-murchison-tzdist-tzif-16</draft>
        <obsoleted-by>
            <doc-id>RFC9636</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8536</errata-url>
        <doi>10.17487/RFC8536</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8537</doc-id>
        <title>Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)</title>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>J. Whittaker</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>RSVP-TE LSP</kw>
        </keywords>
        <abstract><p>Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP.  When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP.  This document updates the fast reroute procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs.  This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs.  The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event.</p></abstract>
        <draft>draft-ietf-teas-assoc-corouted-bidir-frr-07</draft>
        <updates>
            <doc-id>RFC4090</doc-id>
            <doc-id>RFC7551</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8537</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8538</doc-id>
        <title>Notification Message Support for BGP Graceful Restart</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>R. Fernando</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>J. Haas</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IDR</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION messages.  This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires.  This document also defines a new subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.</p></abstract>
        <draft>draft-ietf-idr-bgp-gr-notification-16</draft>
        <updates>
            <doc-id>RFC4724</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8538</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8539</doc-id>
        <title>Softwire Provisioning Using DHCPv4 over DHCPv6</title>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>L. Sun</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Provisioning</kw>
            <kw>Softwire</kw>
            <kw>DHCP 4o6</kw>
            <kw>IPv4 over IPv6</kw>
            <kw>IPv4 service continuity</kw>
            <kw>IPv4 address depletion</kw>
            <kw>IPv4 over IPv6</kw>
            <kw>MAP</kw>
            <kw>Lightweight 4over6</kw>
        </keywords>
        <abstract><p>DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.</p><p> "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.</p></abstract>
        <draft>draft-ietf-dhc-dhcp4o6-saddr-opt-08</draft>
        <updates>
            <doc-id>RFC7598</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8539</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8540</doc-id>
        <title>Stream Control Transmission Protocol: Errata and Issues in RFC 4960</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>M. Proshin</name>
        </author>
        <date>
            <month>February</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <abstract><p>This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes.  This document provides deltas to RFC 4960 and is organized in a time-ordered way.  The issues are listed in the order in which they were brought up.  Because some text is changed several times, the last delta in the text is the one that should be applied.  In addition to the deltas, a description of each problem and the details of the solution for each are also provided.</p></abstract>
        <draft>draft-ietf-tsvwg-rfc4960-errata-08</draft>
        <obsoleted-by>
            <doc-id>RFC9260</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8540</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8541</doc-id>
        <title>Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>M. Horneffer</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>IS-IS</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.</p><p> This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies.</p></abstract>
        <draft>draft-ietf-rtgwg-spf-uloop-pb-statement-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8541</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8542</doc-id>
        <title>A YANG Data Model for Fabric Topology in Data-Center Networks</title>
        <author>
            <name>Y. Zhuang</name>
        </author>
        <author>
            <name>D. Shi</name>
        </author>
        <author>
            <name>R. Gu</name>
        </author>
        <author>
            <name>H. Ananthakrishnan</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>Fabric Topology</kw>
            <kw>Data-Center Networks</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric.  This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model.</p></abstract>
        <draft>draft-ietf-i2rs-yang-dc-fabric-network-topology-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8542</errata-url>
        <doi>10.17487/RFC8542</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8543</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Organization Mapping</title>
        <author>
            <name>L. Zhou</name>
        </author>
        <author>
            <name>N. Kong</name>
        </author>
        <author>
            <name>J. Yao</name>
        </author>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>G. Zhou</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>epp registry organization object mapping</kw>
        </keywords>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository.</p></abstract>
        <draft>draft-ietf-regext-org-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8544</doc-id>
        <title>Organization Extension for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>L. Zhou</name>
        </author>
        <author>
            <name>N. Kong</name>
        </author>
        <author>
            <name>J. Wei</name>
        </author>
        <author>
            <name>J. Yao</name>
        </author>
        <author>
            <name>J. Gould</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>epp organization mapping extension</kw>
        </keywords>
        <abstract><p>This document describes an extension to Extensible Provisioning Protocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.</p></abstract>
        <draft>draft-ietf-regext-org-ext-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8544</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8545</doc-id>
        <title>Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)</title>
        <author>
            <name>A. Morton</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>OWAMP</kw>
            <kw>TWAMP</kw>
        </keywords>
        <abstract><p>This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry.</p><p> This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.</p></abstract>
        <draft>draft-ietf-ippm-port-twamp-test-04</draft>
        <updates>
            <doc-id>RFC4656</doc-id>
            <doc-id>RFC5357</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8545</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8546</doc-id>
        <title>The Wire Image of a Network Protocol</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <author>
            <name>M. Kuehlewind</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol.  This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.</p></abstract>
        <draft>draft-iab-wire-image-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8546</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8547</doc-id>
        <title>TCP-ENO: Encryption Negotiation Option</title>
        <author>
            <name>A. Bittau</name>
        </author>
        <author>
            <name>D. Giffin</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>D. Mazieres</name>
        </author>
        <author>
            <name>E. Smith</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted.  The persistence of unencrypted traffic can be attributed to at least two factors.  First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible.  Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer.  The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.</p></abstract>
        <draft>draft-ietf-tcpinc-tcpeno-19</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpinc</wg_acronym>
        <doi>10.17487/RFC8547</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8548</doc-id>
        <title>Cryptographic Protection of TCP Streams (tcpcrypt)</title>
        <author>
            <name>A. Bittau</name>
        </author>
        <author>
            <name>D. Giffin</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>D. Mazieres</name>
        </author>
        <author>
            <name>Q. Slack</name>
        </author>
        <author>
            <name>E. Smith</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO).  Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header.  The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable.  Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted.  However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection.</p></abstract>
        <draft>draft-ietf-tcpinc-tcpcrypt-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tcpinc</wg_acronym>
        <doi>10.17487/RFC8548</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8549</doc-id>
        <title>Export of BGP Community Information in IP Flow Information Export (IPFIX)</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>R. Gu</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>community</kw>
            <kw>BGP</kw>
            <kw>IPFIX</kw>
        </keywords>
        <abstract><p>By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export (IPFIX) to export BGP community information, including the BGP Standard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092.  According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions.  Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering.</p></abstract>
        <draft>draft-ietf-opsawg-ipfix-bgp-community-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC8549</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8550</doc-id>
        <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>B. Ramsdell</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>S/MIME</kw>
        </keywords>
        <abstract><p>This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 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 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile").  S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280.  This document obsoletes RFC 5750.</p></abstract>
        <draft>draft-ietf-lamps-rfc5750-bis-08</draft>
        <obsoletes>
            <doc-id>RFC5750</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8551</doc-id>
        <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>B. Ramsdell</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>S/MIME</kw>
        </keywords>
        <abstract><p>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0.  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 5751.</p></abstract>
        <draft>draft-ietf-lamps-rfc5751-bis-11</draft>
        <obsoletes>
            <doc-id>RFC5751</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8551</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8552</doc-id>
        <title>Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
        </keywords>
        <abstract><p>Formally, any DNS Resource Record (RR) may occur under any domain name.  However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies.  The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name").  The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch.  This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA.  The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.</p></abstract>
        <draft>draft-ietf-dnsop-attrleaf-16</draft>
        <is-also>
            <doc-id>BCP0222</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8552</errata-url>
        <doi>10.17487/RFC8552</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8553</doc-id>
        <title>DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Domain Name System</kw>
        </keywords>
        <abstract><p>Using an underscore for a prefix creates a space for constrained interoperation of resource records.  Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry.  This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace.  A registry for these names has now been defined by RFC 8552.  However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry.  This document specifies those changes.  The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.</p></abstract>
        <draft>draft-ietf-dnsop-attrleaf-fix-07</draft>
        <updates>
            <doc-id>RFC2782</doc-id>
            <doc-id>RFC3263</doc-id>
            <doc-id>RFC3529</doc-id>
            <doc-id>RFC3620</doc-id>
            <doc-id>RFC3832</doc-id>
            <doc-id>RFC3887</doc-id>
            <doc-id>RFC3958</doc-id>
            <doc-id>RFC4120</doc-id>
            <doc-id>RFC4227</doc-id>
            <doc-id>RFC4386</doc-id>
            <doc-id>RFC4387</doc-id>
            <doc-id>RFC4976</doc-id>
            <doc-id>RFC5026</doc-id>
            <doc-id>RFC5328</doc-id>
            <doc-id>RFC5389</doc-id>
            <doc-id>RFC5415</doc-id>
            <doc-id>RFC5518</doc-id>
            <doc-id>RFC5555</doc-id>
            <doc-id>RFC5617</doc-id>
            <doc-id>RFC5679</doc-id>
            <doc-id>RFC5766</doc-id>
            <doc-id>RFC5780</doc-id>
            <doc-id>RFC5804</doc-id>
            <doc-id>RFC5864</doc-id>
            <doc-id>RFC5928</doc-id>
            <doc-id>RFC6120</doc-id>
            <doc-id>RFC6186</doc-id>
            <doc-id>RFC6376</doc-id>
            <doc-id>RFC6733</doc-id>
            <doc-id>RFC6763</doc-id>
            <doc-id>RFC7208</doc-id>
            <doc-id>RFC7489</doc-id>
            <doc-id>RFC8145</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0222</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8553</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8554</doc-id>
        <title>Leighton-Micali Hash-Based Signatures</title>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>M. Curcio</name>
        </author>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>LMS</kw>
            <kw>HSS</kw>
            <kw>stateful</kw>
        </keywords>
        <abstract><p>This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.</p></abstract>
        <draft>draft-mcgrew-hash-sigs-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8554</errata-url>
        <doi>10.17487/RFC8554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8555</doc-id>
        <title>Automatic Certificate Management Environment (ACME)</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>J. Hoffman-Andrews</name>
        </author>
        <author>
            <name>D. McCarney</name>
        </author>
        <author>
            <name>J. Kasten</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>certificate</kw>
            <kw>HTTPS</kw>
            <kw>PKI</kw>
            <kw>X.509</kw>
        </keywords>
        <abstract><p>Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names.  Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.  As of this writing, this verification is done through a collection of ad hoc mechanisms.  This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.</p></abstract>
        <draft>draft-ietf-acme-acme-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8555</errata-url>
        <doi>10.17487/RFC8555</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8556</doc-id>
        <title>Multicast VPN Using Bit Index Explicit Replication (BIER)</title>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>A. Dolganow</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network.  The P-tunnels are used for carrying multicast traffic across the backbone.  A variety of P-tunnel types are supported.  Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol.  This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.</p></abstract>
        <draft>draft-ietf-bier-mvpn-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <doi>10.17487/RFC8556</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8557</doc-id>
        <title>Deterministic Networking Problem Statement</title>
        <author>
            <name>N. Finn</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.</p></abstract>
        <draft>draft-ietf-detnet-problem-statement-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC8557</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8558</doc-id>
        <title>Transport Protocol Path Signals</title>
        <author>
            <name>T. Hardie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals.  For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear.  Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements.  In transports that do not exchange these messages in the clear, on-path network elements lack those signals.  Often, the removal of those signals is intended by those moving the messages to confidential channels.  Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.</p></abstract>
        <draft>draft-iab-path-signals-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8558</errata-url>
        <doi>10.17487/RFC8558</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8559</doc-id>
        <title>Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>Change of Authorization</kw>
            <kw>CoA-Request</kw>
            <kw>Disconnect-Request</kw>
        </keywords>
        <abstract><p>RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS.  RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done.  This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542.  This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.</p></abstract>
        <draft>draft-ietf-radext-coa-proxy-10</draft>
        <updates>
            <doc-id>RFC5176</doc-id>
            <doc-id>RFC5580</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC8559</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8560</doc-id>
        <title>Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>N. Del Regno</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>EVPN</kw>
            <kw>VPLS</kw>
            <kw>PBB-EVPN</kw>
            <kw>PBB-VPLS</kw>
            <kw>Ethernet Virtual Private Networks</kw>
            <kw>Virtual Private LAN Services</kw>
            <kw>Provider Backbone Bridging</kw>
        </keywords>
        <abstract><p>This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions.  It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis.  Implementation of this document enables service providers to introduce EVPN/PBB-EVPN Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks.  This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media Access Control (MAC) mobility operation.  This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs.</p></abstract>
        <draft>draft-ietf-bess-evpn-vpls-seamless-integ-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8560</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8561</doc-id>
        <title>A YANG Data Model for Microwave Radio Link</title>
        <author>
            <name>J. Ahlberg</name>
        </author>
        <author>
            <name>M. Ye</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>D. Spreafico</name>
        </author>
        <author>
            <name>M. Vaupotic</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>microwaveRadioLinkTerminal</kw>
            <kw>microwaveCarrierTermination</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node.  The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well.</p></abstract>
        <draft>draft-ietf-ccamp-mw-yang-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8561</errata-url>
        <doi>10.17487/RFC8561</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8562</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for Multipoint Networks</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>S. Pallagatti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>Multipoint BFD</kw>
        </keywords>
        <abstract><p>This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.</p><p> This document updates RFC 5880.</p></abstract>
        <draft>draft-ietf-bfd-multipoint-19</draft>
        <updates>
            <doc-id>RFC5880</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9780</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC8562</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8563</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) Multipoint Active Tails</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>S. Pallagatti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks.</p></abstract>
        <draft>draft-ietf-bfd-multipoint-active-tail-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC8563</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8564</doc-id>
        <title>Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>S. Pallagatti</name>
        </author>
        <author>
            <name>V. Govindan</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>data center network</kw>
            <kw>switch</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract><p>Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity.  This document specifies the support of P2MP BFD in Transparent Interconnection of Lots of Links (TRILL).  Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel messages.  This document updates RFCs 7175 and 7177.</p></abstract>
        <draft>draft-ietf-trill-p2mp-bfd-09</draft>
        <updates>
            <doc-id>RFC7175</doc-id>
            <doc-id>RFC7177</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC8564</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8565</doc-id>
        <title>Hypertext Jeopardy Protocol (HTJP/1.0)</title>
        <author>
            <name>E. Fokschaner</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP).  Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer.  Using HTJP, one connects to a server, sends an answer, and expects a correct question.  This document specifies the semantics of HTJP.</p></abstract>
        <draft>draft-fokschaner-htjp-latest-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8565</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8566</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8567</doc-id>
        <title>Customer Management DNS Resource Records</title>
        <author>
            <name>E. Rye</name>
        </author>
        <author>
            <name>R. Beverly</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.</p><p> This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.</p></abstract>
        <draft>draft-ietf-cust-mgmt-dns-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8567</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8568</doc-id>
        <title>Network Virtualization Research Challenges</title>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>A. Rahman</name>
        </author>
        <author>
            <name>JC. Zuniga</name>
        </author>
        <author>
            <name>LM. Contreras</name>
        </author>
        <author>
            <name>P. Aranda</name>
        </author>
        <author>
            <name>P. Lynch</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document describes open research challenges for network virtualization.  Network virtualization is following a similar path as previously taken by cloud computing.  Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet.  In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources.  However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself.  This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing.  In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges.  This document is a product of the Network Function Virtualization Research Group (NFVRG).</p></abstract>
        <draft>draft-irtf-nfvrg-gaps-network-virtualization-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8568</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8569</doc-id>
        <title>Content-Centric Networking (CCNx) Semantics</title>
        <author>
            <name>M. Mosko</name>
        </author>
        <author>
            <name>I. Solis</name>
        </author>
        <author>
            <name>C. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Content Centric Networking</kw>
        </keywords>
        <abstract><p>This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.</p><p> The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.</p><p> This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.</p></abstract>
        <draft>draft-irtf-icnrg-ccnxsemantics-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8569</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8570</doc-id>
        <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
        <author>
            <name>L. Ginsberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Giacalone</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>IS-IS</kw>
        </keywords>
        <abstract><p>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</p><p> This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</p><p> Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</p><p> This document obsoletes RFC 7810.</p></abstract>
        <draft>draft-ietf-lsr-isis-rfc7810bis-05</draft>
        <obsoletes>
            <doc-id>RFC7810</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8571</doc-id>
        <title>BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions</title>
        <author>
            <name>L. Ginsberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <date>
            <month>March</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.</p></abstract>
        <draft>draft-ietf-idr-te-pm-bgp-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8571</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8572</doc-id>
        <title>Secure Zero Touch Provisioning (SZTP)</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>M. Abrahamsson</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>87</page-count>
        <keywords>
            <kw>zerotouch</kw>
            <kw>bootstrap</kw>
            <kw>sztp</kw>
            <kw>ztp</kw>
        </keywords>
        <abstract><p>This document presents a technique to securely provision a networking device when it is booting in a factory-default state.  Variations in the solution enable it to be used on both public and private networks.  The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs.  The updated device is subsequently able to establish secure connections with other systems.  For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</p></abstract>
        <draft>draft-ietf-netconf-zerotouch-29</draft>
        <updated-by>
            <doc-id>RFC9646</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8572</errata-url>
        <doi>10.17487/RFC8572</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8573</doc-id>
        <title>Message Authentication Code for the Network Time Protocol</title>
        <author>
            <name>A. Malhotra</name>
        </author>
        <author>
            <name>S. Goldberg</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>NTP</kw>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag.  This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.</p></abstract>
        <draft>draft-ietf-ntp-mac-06</draft>
        <updates>
            <doc-id>RFC5905</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9748</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC8573</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8574</doc-id>
        <title>cite-as: A Link Relation to Convey a Preferred URI for Referencing</title>
        <author>
            <name>H. Van de Sompel</name>
        </author>
        <author>
            <name>M. Nelson</name>
        </author>
        <author>
            <name>G. Bilder</name>
        </author>
        <author>
            <name>J. Kunze</name>
        </author>
        <author>
            <name>S. Warner</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>persistent identifier</kw>
            <kw>PID</kw>
        </keywords>
        <abstract><p>A web resource is routinely referenced by means of the URI with which it is directly accessed.  But cases exist where referencing a resource by means of a different URI is preferred.  This specification defines a link relation type that can be used to convey such a preference.</p></abstract>
        <draft>draft-vandesompel-citeas-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8574</errata-url>
        <doi>10.17487/RFC8574</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8575</doc-id>
        <title>YANG Data Model for the Precision Time Protocol (PTP)</title>
        <author>
            <name>Y. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>J. Xu</name>
        </author>
        <author>
            <name>R. Cummings</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008.  It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks.  The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-tictoc-1588v2-yang-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tictoc</wg_acronym>
        <doi>10.17487/RFC8575</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8576</doc-id>
        <title>Internet of Things (IoT) Security: State of the Art and Challenges</title>
        <author>
            <name>O. Garcia-Morchon</name>
        </author>
        <author>
            <name>S. Kumar</name>
        </author>
        <author>
            <name>M. Sethi</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>M2M</kw>
            <kw>Machine-to-machine</kw>
            <kw>Machine-type communication</kw>
            <kw>MTC</kw>
            <kw>Security</kw>
            <kw>Privacy</kw>
            <kw>Trustworthy</kw>
            <kw>Lifecycle</kw>
        </keywords>
        <abstract><p>The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.</p><p> This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).</p></abstract>
        <draft>draft-irtf-t2trg-iot-seccons-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8577</doc-id>
        <title>Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane</title>
        <author>
            <name>H. Sitaraman</name>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <author>
            <name>T. Parikh</name>
        </author>
        <author>
            <name>T. Saad</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Segment Routed RSVP-TE tunnels</kw>
            <kw>TE link labels</kw>
            <kw>RSVP-TE shared labels</kw>
        </keywords>
        <abstract><p>As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.</p><p> However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.</p><p> This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.</p></abstract>
        <draft>draft-ietf-mpls-rsvp-shared-labels-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8577</errata-url>
        <doi>10.17487/RFC8577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8578</doc-id>
        <title>Deterministic Networking Use Cases</title>
        <author>
            <name>E. Grossman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>97</page-count>
        <keywords>
            <kw>DetNet</kw>
            <kw>AVB</kw>
            <kw>TSN</kw>
            <kw>SRP</kw>
        </keywords>
        <abstract><p>This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data.  These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet).  For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.</p></abstract>
        <draft>draft-ietf-detnet-use-cases-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC8578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8579</doc-id>
        <title>Sieve Email Filtering: Delivering to Special-Use Mailboxes</title>
        <author>
            <name>S. Bosch</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>sieve</kw>
            <kw>mailbox</kw>
            <kw>special-use</kw>
        </keywords>
        <abstract><p>The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put.  This simplifies client configuration.  In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability.  This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute.</p></abstract>
        <draft>draft-ietf-extra-sieve-special-use-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8579</errata-url>
        <doi>10.17487/RFC8579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8580</doc-id>
        <title>Sieve Extension: File Carbon Copy (FCC)</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <author>
            <name>B. Gondwana</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Sieve</kw>
            <kw>Vacation</kw>
            <kw>Notify</kw>
        </keywords>
        <abstract><p>The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.</p><p> This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively.</p></abstract>
        <draft>draft-ietf-extra-sieve-fcc-09</draft>
        <updates>
            <doc-id>RFC5230</doc-id>
            <doc-id>RFC5435</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8580</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8581</doc-id>
        <title>Diameter Agent Overload and the Peer Overload Report</title>
        <author>
            <name>S. Donovan</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>Overload</kw>
        </keywords>
        <abstract><p>This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683.  The extension defines the Peer Overload report type.  The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.</p></abstract>
        <draft>draft-ietf-dime-agent-overload-11</draft>
        <updates>
            <doc-id>RFC7683</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC8581</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8582</doc-id>
        <title>Diameter Overload Rate Control</title>
        <author>
            <name>S. Donovan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Noel</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>Overload</kw>
        </keywords>
        <abstract><p>This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683.  This extension adds a new overload-control abatement algorithm.  This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node.</p></abstract>
        <draft>draft-ietf-dime-doic-rate-control-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC8582</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8583</doc-id>
        <title>Diameter Load Information Conveyance</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>S. Donovan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>JJ. Trottin</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Diameter</kw>
            <kw>load</kw>
        </keywords>
        <abstract><p>RFC 7068 describes requirements for Overload Control in Diameter.  This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded.  The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information.  This document defines a mechanism for the conveying of Diameter load information.</p></abstract>
        <draft>draft-ietf-dime-load-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC8583</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8584</doc-id>
        <title>Framework for Ethernet VPN Designated Forwarder Election Extensibility</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Mohanty</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>K. Nagaraj</name>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <abstract><p>An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined.  The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES).  In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified.  This document clarifies the DF election Finite State Machine in EVPN services.  Therefore, it updates the EVPN specification (RFC 7432).</p></abstract>
        <draft>draft-ietf-bess-evpn-df-election-framework-09</draft>
        <updates>
            <doc-id>RFC7432</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9722</doc-id>
            <doc-id>RFC9785</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8584</errata-url>
        <doi>10.17487/RFC8584</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8585</doc-id>
        <title>Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service</title>
        <author>
            <name>J. Palet Martinez</name>
        </author>
        <author>
            <name>H. M.-H. Liu</name>
        </author>
        <author>
            <name>M. Kawashima</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IPv6 transition</kw>
            <kw>CE requirements</kw>
            <kw>IPv4aaS</kw>
        </keywords>
        <abstract><p>This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.</p><p> Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.</p></abstract>
        <draft>draft-ietf-v6ops-transition-ipv4aas-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8585</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8586</doc-id>
        <title>Loop Detection in Content Delivery Networks (CDNs)</title>
        <author>
            <name>S. Ludin</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>N. Sullivan</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>CDN-Loop,</kw>
        </keywords>
        <abstract><p>This document defines the CDN-Loop request header field for HTTP.  CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop.  The new header field can be used to identify the error and terminate the loop.</p></abstract>
        <draft>draft-ietf-httpbis-cdn-loop-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8586</errata-url>
        <doi>10.17487/RFC8586</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8587</doc-id>
        <title>NFS Version 4.0 Trunking Update</title>
        <author>
            <name>C. Lever</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Noveck</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>NFSv4.0</kw>
            <kw>migration</kw>
            <kw>replication</kw>
            <kw>trunking</kw>
            <kw>fs_locations</kw>
            <kw>transparent state migration</kw>
        </keywords>
        <abstract><p>In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems.  An NFS version 4.0 client can use this information to handle migration and replication of server file systems.  This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities.  This document updates RFC 7530.</p></abstract>
        <draft>draft-ietf-nfsv4-mv0-trunking-update-05</draft>
        <updates>
            <doc-id>RFC7530</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8588</doc-id>
        <title>Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)</title>
        <author>
            <name>C. Wendt</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications.  The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group.  It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.</p></abstract>
        <draft>draft-ietf-stir-passport-shaken-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8588</errata-url>
        <doi>10.17487/RFC8588</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8589</doc-id>
        <title>The 'leaptofrogans' URI Scheme</title>
        <author>
            <name>A. Tamas</name>
        </author>
        <author>
            <name>B. Phister</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J-E. Rodriguez</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Frogans</kw>
            <kw>leaptofrogans</kw>
            <kw>OP3FT</kw>
            <kw>URI scheme</kw>
        </keywords>
        <abstract><p>This document describes the 'leaptofrogans' Uniform Resource Identifier (URI) scheme, which enables applications to launch Frogans Player on a given Frogans site.  Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet.  Frogans Player is software that enables end users to browse Frogans sites.</p></abstract>
        <draft>draft-op3ft-leaptofrogans-uri-scheme-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8589</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8590</doc-id>
        <title>Change Poll Extension for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>K. Feher</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP.  These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests.  Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.</p></abstract>
        <draft>draft-ietf-regext-change-poll-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8590</errata-url>
        <doi>10.17487/RFC8590</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8591</doc-id>
        <title>SIP-Based Messaging with S/MIME</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>MSRP</kw>
            <kw>CPIM</kw>
        </keywords>
        <abstract><p>Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP).  While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection.  This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME).  It updates and provides clarifications for RFCs 3261, 3428, and 4975.</p></abstract>
        <draft>draft-campbell-sip-messaging-smime-05</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3428</doc-id>
            <doc-id>RFC4975</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8591</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8592</doc-id>
        <title>Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)</title>
        <author>
            <name>R. Browne</name>
        </author>
        <author>
            <name>A. Chilikin</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Timestamp</kw>
            <kw>Timestamping</kw>
            <kw>QoS</kw>
            <kw>service chain</kw>
        </keywords>
        <abstract><p>This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH).  These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.</p></abstract>
        <draft>draft-browne-sfc-nsh-kpi-stamp-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8592</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8593</doc-id>
        <title>Video Traffic Models for RTP Congestion Control Evaluations</title>
        <author>
            <name>X. Zhu</name>
        </author>
        <author>
            <name>S. Mena</name>
        </author>
        <author>
            <name>Z. Sarker</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Multimedia</kw>
            <kw>Congestion Control</kw>
        </keywords>
        <abstract><p>This document describes two reference video traffic models for evaluating RTP congestion control algorithms.  The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate.  The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence.  Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module.  Finally, the document describes how both approaches can be combined into a hybrid model.</p></abstract>
        <draft>draft-ietf-rmcat-video-traffic-model-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8593</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8594</doc-id>
        <title>The Sunset HTTP Header Field</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future.  It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.</p></abstract>
        <draft>draft-wilde-sunset-header-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8594</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8595</doc-id>
        <title>An MPLS-Based Forwarding Plane for Service Function Chaining</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>SFC</kw>
            <kw>MPLS</kw>
            <kw>Service Function Chaining</kw>
            <kw>NSH</kw>
            <kw>Network Service Header</kw>
            <kw>MPLS</kw>
            <kw>Multiprotocol Label Switching</kw>
        </keywords>
        <abstract><p>This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack.  That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack.  This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.</p></abstract>
        <draft>draft-ietf-mpls-sfc-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8595</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8596</doc-id>
        <title>MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>label</kw>
            <kw>label stack</kw>
            <kw>service function forwarder (SFF)</kw>
        </keywords>
        <abstract><p>This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame.  This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.</p></abstract>
        <draft>draft-ietf-mpls-sfc-encapsulation-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8596</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8597</doc-id>
        <title>Cooperating Layered Architecture for Software-Defined Networking (CLAS)</title>
        <author>
            <name>LM. Contreras</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>P. Iovanna</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SDN</kw>
            <kw>Control</kw>
            <kw>Programmability</kw>
            <kw>Intelligence</kw>
            <kw>Transport</kw>
            <kw>Service</kw>
            <kw>Flexibility</kw>
            <kw>Cooperation</kw>
        </keywords>
        <abstract><p>Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.</p><p> This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.</p></abstract>
        <draft>draft-contreras-layered-sdn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8597</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8598</doc-id>
        <title>Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IKEv2</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2).  These payloads add support for private (internal-only) DNS domains.  These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection.  DNS resolution for other domains remains unchanged.  These Configuration Payloads only apply to split- tunnel configurations.</p></abstract>
        <draft>draft-ietf-ipsecme-split-dns-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8598</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8599</doc-id>
        <title>Push Notification with the Session Initiation Protocol (SIP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>M. Arnold</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Push</kw>
            <kw>Notification</kw>
        </keywords>
        <abstract><p>This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended.  The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA.  It also defines the parameters to trigger such push notification requests.  The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.</p></abstract>
        <draft>draft-ietf-sipcore-sip-push-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8599</errata-url>
        <doi>10.17487/RFC8599</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8600</doc-id>
        <title>Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange</title>
        <author>
            <name>N. Cam-Winget</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Appala</name>
        </author>
        <author>
            <name>S. Pope</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>publish</kw>
            <kw>subscribe</kw>
            <kw>pubsub</kw>
            <kw>grid</kw>
            <kw>iodef</kw>
            <kw>xmpp-grid</kw>
            <kw>information sharing</kw>
        </keywords>
        <abstract><p>This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities.  To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).</p></abstract>
        <draft>draft-ietf-mile-xmpp-grid-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <doi>10.17487/RFC8600</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8601</doc-id>
        <title>Message Header Field for Indicating Message Authentication Status</title>
        <author>
            <name>M. Kucherawy</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>SPF</kw>
            <kw>ATPS</kw>
            <kw>VBR</kw>
            <kw>Authentication</kw>
            <kw>Reputation</kw>
        </keywords>
        <abstract><p>This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.</p><p> This document obsoletes RFC 7601.</p></abstract>
        <draft>draft-ietf-dmarc-rfc7601bis-06</draft>
        <obsoletes>
            <doc-id>RFC7601</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dmarc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8601</errata-url>
        <doi>10.17487/RFC8601</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8602</doc-id>
        <title>Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.</p><p> This memo updates RFC 3219.</p></abstract>
        <draft>draft-arkko-trip-registry-update-01</draft>
        <updates>
            <doc-id>RFC3219</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8602</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8603</doc-id>
        <title>Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>M. Jenkins</name>
        </author>
        <author>
            <name>L. Zieglar</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite.  The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates.  US National Security Systems are described in NIST Special Publication 800-59.  It is also appropriate for all other US Government systems that process high-value information.  It is made publicly available for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-jenkins-cnsa-cert-crl-profile-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8604</doc-id>
        <title>Interconnecting Millions of Endpoints with Segment Routing</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>G. Dawra</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>D. Cooper</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints.  This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks.  Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries.  This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.</p></abstract>
        <draft>draft-filsfils-spring-large-scale-interconnect-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8604</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8605</doc-id>
        <title>vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>R. Carney</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>vCard</kw>
        </keywords>
        <abstract><p>This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP).  The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.</p></abstract>
        <draft>draft-hollenbeck-vcarddav-icann-rdap-extensions-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8605</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8606</doc-id>
        <title>ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field</title>
        <author>
            <name>R. Jesske</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Reason</kw>
            <kw>Call</kw>
            <kw>Location</kw>
        </keywords>
        <abstract><p>The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes.  Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release.  This document updates RFC 3326 by adding a location parameter for this purpose.</p></abstract>
        <draft>draft-ietf-sipcore-reason-q850-loc-07</draft>
        <updates>
            <doc-id>RFC3326</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8606</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8607</doc-id>
        <title>Calendaring Extensions to WebDAV (CalDAV): Managed Attachments</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>A. Quillaud</name>
        </author>
        <author>
            <name>K. Murchison</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>CalDAV</kw>
            <kw>calendaring</kw>
            <kw>attachment</kw>
            <kw>ATTACH</kw>
        </keywords>
        <abstract><p>This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.</p><p> This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP.</p></abstract>
        <draft>draft-ietf-calext-caldav-attachments-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <doi>10.17487/RFC8607</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8608</doc-id>
        <title>BGPsec Algorithms, Key Formats, and Signature Formats</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>O. Borchert</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>BGPsec</kw>
            <kw>BGPsec Algorithms</kw>
            <kw>Crypto Algorithms</kw>
            <kw>ECDSA</kw>
            <kw>Cryptography</kw>
        </keywords>
        <abstract><p>This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.</p><p> This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.</p></abstract>
        <draft>draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05</draft>
        <obsoletes>
            <doc-id>RFC8208</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC7935</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8608</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8609</doc-id>
        <title>Content-Centric Networking (CCNx) Messages in TLV Format</title>
        <author>
            <name>M. Mosko</name>
        </author>
        <author>
            <name>I. Solis</name>
        </author>
        <author>
            <name>C. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>46</page-count>
        <abstract><p>Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.</p><p> This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.</p></abstract>
        <draft>draft-irtf-icnrg-ccnxmessages-09</draft>
        <updated-by>
            <doc-id>RFC9510</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8609</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8610</doc-id>
        <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
        <author>
            <name>H. Birkholz</name>
        </author>
        <author>
            <name>C. Vigano</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>description language</kw>
            <kw>schema language</kw>
            <kw>tree grammar</kw>
        </keywords>
        <abstract><p>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</p></abstract>
        <draft>draft-ietf-cbor-cddl-08</draft>
        <updated-by>
            <doc-id>RFC9682</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8610</errata-url>
        <doi>10.17487/RFC8610</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8611</doc-id>
        <title>Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces</title>
        <author>
            <name>N. Akiya</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LSP Ping</kw>
        </keywords>
        <abstract><p>This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).</p><p> This document updates RFC 8029.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-lag-multipath-08</draft>
        <updates>
            <doc-id>RFC8029</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9041</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8611</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8612</doc-id>
        <title>DDoS Open Threat Signaling (DOTS) Requirements</title>
        <author>
            <name>A. Mortensen</name>
        </author>
        <author>
            <name>T. Reddy</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.</p></abstract>
        <draft>draft-ietf-dots-requirements-22</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC8612</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8613</doc-id>
        <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>J. Mattsson</name>
        </author>
        <author>
            <name>F. Palombini</name>
        </author>
        <author>
            <name>L. Seitz</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>94</page-count>
        <abstract><p>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</p><p> Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.</p></abstract>
        <draft>draft-ietf-core-object-security-16</draft>
        <updates>
            <doc-id>RFC7252</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8613</errata-url>
        <doi>10.17487/RFC8613</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8614</doc-id>
        <title>Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)</title>
        <author>
            <name>R. Singh</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>S. Palislamovic</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761.  This document updates RFC 4761.</p></abstract>
        <draft>draft-ietf-bess-bgp-vpls-control-flags-08</draft>
        <updates>
            <doc-id>RFC4761</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8614</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8615</doc-id>
        <title>Well-Known Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>May</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</p><p> In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</p></abstract>
        <draft>draft-nottingham-rfc5785bis-11</draft>
        <obsoletes>
            <doc-id>RFC5785</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC7230</doc-id>
            <doc-id>RFC7595</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8616</doc-id>
        <title>Email Authentication for Internationalized Mail</title>
        <author>
            <name>J. Levine</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>email</kw>
            <kw>internationalization</kw>
        </keywords>
        <abstract><p>Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS.  In internationalized email, domain names can occur both as U-labels and A-labels.  This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.</p></abstract>
        <draft>draft-ietf-dmarc-eaiauth-06</draft>
        <updates>
            <doc-id>RFC6376</doc-id>
            <doc-id>RFC7208</doc-id>
            <doc-id>RFC7489</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dmarc</wg_acronym>
        <doi>10.17487/RFC8616</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8617</doc-id>
        <title>The Authenticated Received Chain (ARC) Protocol</title>
        <author>
            <name>K. Andersen</name>
        </author>
        <author>
            <name>B. Long</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Blank</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>DKIM</kw>
            <kw>DMARC</kw>
            <kw>signature</kw>
            <kw>email</kw>
            <kw>domian authentication</kw>
            <kw>email authentication</kw>
        </keywords>
        <abstract><p>The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.</p><p> ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.</p><p> ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.</p></abstract>
        <draft>draft-ietf-dmarc-arc-protocol-23</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dmarc</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8617</errata-url>
        <doi>10.17487/RFC8617</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8618</doc-id>
        <title>Compacted-DNS (C-DNS): A Format for DNS Packet Capture</title>
        <author>
            <name>J. Dickinson</name>
        </author>
        <author>
            <name>J. Hague</name>
        </author>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>T. Manderson</name>
        </author>
        <author>
            <name>J. Bond</name>
        </author>
        <date>
            <month>September</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document describes a data representation for collections of DNS messages.  The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata.  It is intended to assist with the development of DNS traffic- monitoring applications.</p></abstract>
        <draft>draft-ietf-dnsop-dns-capture-format-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8618</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8619</doc-id>
        <title>Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>HKDF</kw>
            <kw>Algorithm Identifier</kw>
        </keywords>
        <abstract><p>RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm.  This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.</p></abstract>
        <draft>draft-housley-hkdf-oids-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8619</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8620</doc-id>
        <title>The JSON Meta Application Protocol (JMAP)</title>
        <author>
            <name>N. Jenkins</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</p></abstract>
        <draft>draft-ietf-jmap-core-17</draft>
        <updated-by>
            <doc-id>RFC9404</doc-id>
            <doc-id>RFC9670</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8620</errata-url>
        <doi>10.17487/RFC8620</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8621</doc-id>
        <title>The JSON Meta Application Protocol (JMAP) for Mail</title>
        <author>
            <name>N. Jenkins</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>108</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP).  Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.</p></abstract>
        <draft>draft-ietf-jmap-mail-16</draft>
        <updates>
            <doc-id>RFC5788</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC8621</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8622</doc-id>
        <title>A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services</title>
        <author>
            <name>R. Bless</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Lower Effort</kw>
            <kw>Per-Hop Behavior</kw>
            <kw>Scavenger Service</kw>
        </keywords>
        <abstract><p>This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.</p><p> This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.</p></abstract>
        <draft>draft-ietf-tsvwg-le-phb-10</draft>
        <obsoletes>
            <doc-id>RFC3662</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4594</doc-id>
            <doc-id>RFC8325</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8622</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8623</doc-id>
        <title>Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
        <author>
            <name>U. Palle</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Y. Tanaka</name>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs).  This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-p2mp-13</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8623</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8624</doc-id>
        <title>Algorithm Implementation Requirements and Usage Guidance for DNSSEC</title>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>O. Sury</name>
        </author>
        <date>
            <month>June</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence.  To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support.  This document defines the current algorithm implementation requirements and usage guidance for DNSSEC.  This document obsoletes RFC 6944.</p></abstract>
        <draft>draft-ietf-dnsop-algorithm-update-10</draft>
        <obsoletes>
            <doc-id>RFC6944</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9157</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8624</errata-url>
        <doi>10.17487/RFC8624</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8625</doc-id>
        <title>Ethernet Traffic Parameters with Availability Information</title>
        <author>
            <name>H. Long</name>
        </author>
        <author>
            <name>M. Ye</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. D'Alessandro</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>RSVP-TE</kw>
            <kw>microwave</kw>
            <kw>variable bandwidth link</kw>
        </keywords>
        <abstract><p>A packet-switching network may contain links with variable bandwidths (e.g., copper and radio).  The bandwidth of such links is sensitive to the external environment (e.g., climate).  Availability is typically used to describe these links when doing network planning.  This document introduces an optional Bandwidth Availability TLV in RSVP-TE signaling.  This extension can be used to set up a GMPLS Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object.</p></abstract>
        <draft>draft-ietf-ccamp-rsvp-te-bandwidth-availability-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC8625</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8626</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8627</doc-id>
        <title>RTP Payload Format for Flexible Forward Error Correction (FEC)</title>
        <author>
            <name>M. Zanaty</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>G. Mandyam</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>forward error correction</kw>
        </keywords>
        <abstract><p>This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP.  These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams.  These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets.  RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received.  The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity.  The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements.  Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.</p></abstract>
        <draft>draft-ietf-payload-flexible-fec-scheme-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>payload</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8627</errata-url>
        <doi>10.17487/RFC8627</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8628</doc-id>
        <title>OAuth 2.0 Device Authorization Grant</title>
        <author>
            <name>W. Denniss</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Security Area</kw>
            <kw>OAuth</kw>
            <kw>Security</kw>
            <kw>Authorization</kw>
            <kw>Smart Objects</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>Internet of Things Security</kw>
            <kw>OAuth for Constrained Devices</kw>
            <kw>OAuth IoT Security</kw>
        </keywords>
        <abstract><p>The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical.  It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.</p></abstract>
        <draft>draft-ietf-oauth-device-flow-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8628</errata-url>
        <doi>10.17487/RFC8628</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8629</doc-id>
        <title>Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension</title>
        <author>
            <name>B. Cheng</name>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.</p></abstract>
        <draft>draft-ietf-manet-dlep-multi-hop-extension-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8629</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8630</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Trust Anchor Locator</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>S. Weiler</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>T. Bruijnzeels</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.</p><p> This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.</p></abstract>
        <draft>draft-ietf-sidrops-https-tal-08</draft>
        <obsoletes>
            <doc-id>RFC7730</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8630</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8631</doc-id>
        <title>Link Relation Types for Web Services</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>API</kw>
            <kw>Documentation</kw>
            <kw>Description</kw>
            <kw>Metadata</kw>
            <kw>Status</kw>
        </keywords>
        <abstract><p>Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider.  Often, these sets of resources are referred to as "Web services" or "Web APIs".  This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources.  Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers.  Metadata provides information about a service's context.  This specification also defines a link relation to identify status resources that are used to represent information about service status.</p></abstract>
        <draft>draft-wilde-service-link-rel-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8632</doc-id>
        <title>A YANG Data Model for Alarm Management</title>
        <author>
            <name>S. Vallin</name>
        </author>
        <author>
            <name>M. Bjorklund</name>
        </author>
        <date>
            <month>September</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>Monitoring</kw>
            <kw>Fault Management</kw>
        </keywords>
        <abstract><p>This document defines a YANG module for alarm management.  It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems.  There are also operations to manage the operator state of an alarm and administrative alarm procedures.  The module carefully maps to relevant alarm standards.</p></abstract>
        <draft>draft-ietf-ccamp-alarm-module-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8632</errata-url>
        <doi>10.17487/RFC8632</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8633</doc-id>
        <title>Network Time Protocol Best Current Practices</title>
        <author>
            <name>D. Reilly</name>
        </author>
        <author>
            <name>H. Stenn</name>
        </author>
        <author>
            <name>D. Sibold</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>NTP</kw>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication.  This document is a collection of best practices for the general operation of NTP servers and clients on the Internet.  It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure.  This document is targeted at NTP version 4 as described in RFC 5905.</p></abstract>
        <draft>draft-ietf-ntp-bcp-13</draft>
        <is-also>
            <doc-id>BCP0223</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC8633</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8634</doc-id>
        <title>BGPsec Router Certificate Rollover</title>
        <author>
            <name>B. Weis</name>
        </author>
        <author>
            <name>R. Gagliano</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates.  The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys.  This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary.  When this rollover process is followed, the rollover will be performed without routing information being lost.</p></abstract>
        <draft>draft-ietf-sidrops-bgpsec-rollover-04</draft>
        <is-also>
            <doc-id>BCP0224</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8634</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8635</doc-id>
        <title>Router Keying for BGPsec</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements.  The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages.  This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.</p></abstract>
        <draft>draft-ietf-sidrops-rtr-keying-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8635</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8636</doc-id>
        <title>Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility</title>
        <author>
            <name>L. Hornquist Astrand</name>
        </author>
        <author>
            <name>L. Zhu</name>
        </author>
        <author>
            <name>M. Cullen</name>
        </author>
        <author>
            <name>G. Hudson</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.</p><p> These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms.</p></abstract>
        <draft>draft-ietf-kitten-pkinit-alg-agility-08</draft>
        <updates>
            <doc-id>RFC4556</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC8636</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8637</doc-id>
        <title>Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>July</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>ACTN</kw>
        </keywords>
        <abstract><p>Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.</p><p> The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).</p><p> This document examines the applicability of PCE to the ACTN framework.</p></abstract>
        <draft>draft-ietf-pce-applicability-actn-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8637</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8638</doc-id>
        <title>IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks</title>
        <author>
            <name>M. Xu</name>
        </author>
        <author>
            <name>Y. Cui</name>
        </author>
        <author>
            <name>J. Wu</name>
        </author>
        <author>
            <name>S. Yang</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <date>
            <month>September</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>Mesh</kw>
            <kw>SSM</kw>
            <kw>ASM</kw>
        </keywords>
        <abstract><p>During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.</p><p> This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ. The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario.</p></abstract>
        <draft>draft-ietf-softwire-mesh-multicast-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8638</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8639</doc-id>
        <title>Subscription to YANG Notifications</title>
        <author>
            <name>E. Voit</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>A. Gonzalez Prieto</name>
        </author>
        <author>
            <name>E. Nilsen-Nygaard</name>
        </author>
        <author>
            <name>A. Tripathy</name>
        </author>
        <date>
            <month>September</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>77</page-count>
        <keywords>
            <kw>telemetry</kw>
            <kw>YANG-Push</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams.  Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.</p></abstract>
        <draft>draft-ietf-netconf-subscribed-notifications-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8639</errata-url>
        <doi>10.17487/RFC8639</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8640</doc-id>
        <title>Dynamic Subscription to YANG Events and Datastores over NETCONF</title>
        <author>
            <name>E. Voit</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>A. Gonzalez Prieto</name>
        </author>
        <author>
            <name>E. Nilsen-Nygaard</name>
        </author>
        <author>
            <name>A. Tripathy</name>
        </author>
        <date>
            <month>September</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>telemetry</kw>
        </keywords>
        <abstract><p>This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.</p></abstract>
        <draft>draft-ietf-netconf-netconf-event-notifications-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8640</errata-url>
        <doi>10.17487/RFC8640</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8641</doc-id>
        <title>Subscription to YANG Notifications for Datastore Updates</title>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>E. Voit</name>
        </author>
        <date>
            <month>September</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>YANG-Push</kw>
            <kw>Streaming</kw>
            <kw>telemetry</kw>
        </keywords>
        <abstract><p>This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore.  Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.</p></abstract>
        <draft>draft-ietf-netconf-yang-push-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC8641</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8642</doc-id>
        <title>Policy Behavior for Well-Known BGP Communities</title>
        <author>
            <name>J. Borkenhagen</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>S. Bayraktar</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Operations</kw>
            <kw>Inter-Provider Communication</kw>
        </keywords>
        <abstract><p>Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators.  Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration.  This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward.  These behavioral changes, though subtle, actually update RFC 1997.</p></abstract>
        <draft>draft-ietf-grow-wkc-behavior-08</draft>
        <updates>
            <doc-id>RFC1997</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC8642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8643</doc-id>
        <title>An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>A. Hutton</name>
        </author>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>T. Stach</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>srtp</kw>
            <kw>opportunistic security</kw>
            <kw>encryption</kw>
            <kw>best effort</kw>
            <kw>osrtp</kw>
        </keywords>
        <abstract><p>Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to the Real-time Transport Protocol (RTP).  OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required.  OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets.  OSRTP is not specific to any key management technique for Secure RTP (SRTP).  OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state.</p></abstract>
        <draft>draft-ietf-sipbrandy-osrtp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipbrandy</wg_acronym>
        <doi>10.17487/RFC8643</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8644</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8645</doc-id>
        <title>Re-keying Mechanisms for Symmetric Keys</title>
        <author>
            <name>S. Smyshlyaev</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>69</page-count>
        <keywords>
            <kw>re-keying</kw>
            <kw>key</kw>
            <kw>key lifetime</kw>
            <kw>encryption mode</kw>
            <kw>mode of operation</kw>
        </keywords>
        <abstract><p>A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-re-keying-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8645</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8646</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8647</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8648</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8649</doc-id>
        <title>Hash Of Root Key Certificate Extension</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <file-format>HTML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>trust anchor</kw>
        </keywords>
        <abstract><p>This document specifies the Hash Of Root Key certificate extension.  This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate.  This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.</p></abstract>
        <draft>draft-ietf-lamps-hash-of-root-key-cert-extn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8649</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8650</doc-id>
        <title>Dynamic Subscription to YANG Events and Datastores over RESTCONF</title>
        <author>
            <name>E. Voit</name>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>E. Nilsen-Nygaard</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>YANG-Push</kw>
        </keywords>
        <abstract><p>This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.</p></abstract>
        <draft>draft-ietf-netconf-restconf-notif-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8650</errata-url>
        <doi>10.17487/RFC8650</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8651</doc-id>
        <title>Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension</title>
        <author>
            <name>B. Cheng</name>
        </author>
        <author>
            <name>D. Wiggins</name>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DLEP</kw>
            <kw>Flow control</kw>
            <kw>Pause</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.</p></abstract>
        <draft>draft-ietf-manet-dlep-pause-extension-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8651</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8652</doc-id>
        <title>A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)</title>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>F. Guo</name>
        </author>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <author>
            <name>P. McAllister</name>
        </author>
        <author>
            <name>A. Peter</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>IGMP</kw>
            <kw>MLD</kw>
            <kw>multicast</kw>
            <kw>data model</kw>
            <kw>ietf-igmp-mld</kw>
            <kw>network management</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices.</p></abstract>
        <draft>draft-ietf-pim-igmp-mld-yang-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC8652</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8653</doc-id>
        <title>On-Demand Mobility Management</title>
        <author>
            <name>A. Yegin</name>
        </author>
        <author>
            <name>D. Moses</name>
        </author>
        <author>
            <name>S. Jeon</name>
        </author>
        <date>
            <month>October</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Applications differ with respect to whether they need session continuity and/or IP address reachability.  The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333.  This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept.</p></abstract>
        <draft>draft-ietf-dmm-ondemand-mobility-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8654</doc-id>
        <title>Extended Message Support for BGP</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>D. Ward</name>
        </author>
        <date>
            <month>October</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>border gateway protocol</kw>
            <kw>address family identifiers</kw>
            <kw>afi</kw>
        </keywords>
        <abstract><p>The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets.  As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets.  This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.</p></abstract>
        <draft>draft-ietf-idr-bgp-extended-messages-36</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8654</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8655</doc-id>
        <title>Deterministic Networking Architecture</title>
        <author>
            <name>N. Finn</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>B. Varga</name>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <date>
            <month>October</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>TSN</kw>
            <kw>Bounded Latency</kw>
            <kw>Reliable Networking</kw>
            <kw>Available Networking</kw>
        </keywords>
        <abstract><p>This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain.  Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path.  DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</p></abstract>
        <draft>draft-ietf-detnet-architecture-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC8655</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8656</doc-id>
        <title>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)</title>
        <author>
            <name>T. Reddy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Johnston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Matthews</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>NAT</kw>
            <kw>TURN</kw>
            <kw>STUN</kw>
            <kw>ICE</kw>
        </keywords>
        <abstract><p>If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.</p><p> The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.</p><p> This document obsoletes RFCs 5766 and 6156.</p></abstract>
        <draft>draft-ietf-tram-turnbis-29</draft>
        <obsoletes>
            <doc-id>RFC5766</doc-id>
            <doc-id>RFC6156</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>tram</wg_acronym>
        <doi>10.17487/RFC8656</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8657</doc-id>
        <title>Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding</title>
        <author>
            <name>H. Landau</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity.  However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy.  This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required.</p></abstract>
        <draft>draft-ietf-acme-caa-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC8657</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8658</doc-id>
        <title>RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)</title>
        <author>
            <name>S. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Fu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Xie</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>IPv6 Transition</kw>
            <kw>MAP-E</kw>
            <kw>MAP-T</kw>
            <kw>Lightweight 4over6</kw>
            <kw>RADIUS</kw>
            <kw>address sharing</kw>
            <kw>authorization</kw>
            <kw>AAA</kw>
            <kw>provisioning</kw>
        </keywords>
        <abstract><p>IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.</p><p> This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.</p></abstract>
        <draft>draft-ietf-softwire-map-radius-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8658</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8659</doc-id>
        <title>DNS Certification Authority Authorization (CAA) Resource Record</title>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <author>
            <name>R. Stradling</name>
        </author>
        <author>
            <name>J. Hoffman-Andrews</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>certificate</kw>
            <kw>ca</kw>
            <kw>pki</kw>
            <kw>issue</kw>
            <kw>issuance</kw>
            <kw>wildcard</kw>
        </keywords>
        <abstract><p>The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs.</p><p> This document obsoletes RFC 6844.</p></abstract>
        <draft>draft-ietf-lamps-rfc6844bis-07</draft>
        <obsoletes>
            <doc-id>RFC6844</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8659</errata-url>
        <doi>10.17487/RFC8659</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8660</doc-id>
        <title>Segment Routing with the MPLS Data Plane</title>
        <author>
            <name>A. Bashandy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>SR</kw>
            <kw>SR-MPLS</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) leverages the source-routing paradigm.  A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header.  In the MPLS data plane, the SR header is instantiated through a label stack.  This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).</p></abstract>
        <draft>draft-ietf-spring-segment-routing-mpls-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC8660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8661</doc-id>
        <title>Segment Routing MPLS Interworking with LDP</title>
        <author>
            <name>A. Bashandy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SR-MPLS</kw>
        </keywords>
        <abstract><p>A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain.</p><p> The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist.</p></abstract>
        <draft>draft-ietf-spring-segment-routing-ldp-interop-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC8661</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8662</doc-id>
        <title>Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels</title>
        <author>
            <name>S. Kini</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Flow-aware load balancing</kw>
            <kw>ECMP (equal-cost multipath)</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) leverages the source-routing paradigm.  A node steers a packet through an ordered list of instructions, called segments.  Segment Routing can be applied to the Multiprotocol Label Switching (MPLS) data plane.  Entropy labels (ELs) are used in MPLS to improve load-balancing.  This document examines and describes how ELs are to be applied to Segment Routing MPLS.</p></abstract>
        <draft>draft-ietf-mpls-spring-entropy-label-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8662</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8663</doc-id>
        <title>MPLS Segment Routing over IP</title>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>S. Hassan</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SR-MPLS</kw>
            <kw>MPLS-in-UDP</kw>
        </keywords>
        <abstract><p>MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.</p><p> This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP as defined in RFC 7510.</p></abstract>
        <draft>draft-ietf-mpls-sr-over-ip-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8663</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8664</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing</title>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Hardwick</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>SR</kw>
            <kw>Traffic-Engineering</kw>
            <kw>PCE</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.</p><p> This document updates RFC 8408.</p></abstract>
        <draft>draft-ietf-pce-segment-routing-16</draft>
        <updates>
            <doc-id>RFC8408</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8664</errata-url>
        <doi>10.17487/RFC8664</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8665</doc-id>
        <title>OSPF Extensions for Segment Routing</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>R. Shakir</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>SID</kw>
            <kw>IGP</kw>
            <kw>OSPF</kw>
            <kw>Label advertisement</kw>
            <kw>Segment Routing</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</p><p> This document describes the OSPFv2 extensions required for Segment Routing.</p></abstract>
        <draft>draft-ietf-ospf-segment-routing-extensions-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8665</errata-url>
        <doi>10.17487/RFC8665</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8666</doc-id>
        <title>OSPFv3 Extensions for Segment Routing</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>SID</kw>
            <kw>IGP</kw>
            <kw>OSPF</kw>
            <kw>Label advertisement</kw>
            <kw>Segment Routing</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</p><p> This document describes the OSPFv3 extensions required for Segment Routing with the MPLS data plane.</p></abstract>
        <draft>draft-ietf-ospf-ospfv3-segment-routing-extensions-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8666</errata-url>
        <doi>10.17487/RFC8666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8667</doc-id>
        <title>IS-IS Extensions for Segment Routing</title>
        <author>
            <name>S. Previdi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>A. Bashandy</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>SID</kw>
            <kw>IGP</kw>
            <kw>IS-IS</kw>
            <kw>Label advertisement</kw>
            <kw>Segment Routing</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</p><p> This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.</p></abstract>
        <draft>draft-ietf-isis-segment-routing-extensions-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8667</errata-url>
        <doi>10.17487/RFC8667</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8668</doc-id>
        <title>Advertising Layer 2 Bundle Member Link Attributes in IS-IS</title>
        <author>
            <name>L. Ginsberg</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Bashandy</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>M. Nanduri</name>
        </author>
        <author>
            <name>E. Aries</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.</p><p> This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.</p></abstract>
        <draft>draft-ietf-isis-l2bundles-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>isis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8668</errata-url>
        <doi>10.17487/RFC8668</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8669</doc-id>
        <title>Segment Routing Prefix Segment Identifier Extensions for BGP</title>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sreekantiah</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SR</kw>
            <kw>MPLS</kw>
            <kw>BGP</kw>
            <kw>Prefix-SID</kw>
            <kw>Label-Index</kw>
            <kw>SRGB</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.</p><p> This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.</p></abstract>
        <draft>draft-ietf-idr-bgp-prefix-sid-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8669</errata-url>
        <doi>10.17487/RFC8669</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8670</doc-id>
        <title>BGP Prefix Segment in Large-Scale Data Centers</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>G. Dawra</name>
        </author>
        <author>
            <name>E. Aries</name>
        </author>
        <author>
            <name>P. Lapukhov</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SR</kw>
            <kw>MSDC</kw>
            <kw>DC</kw>
            <kw>SRGB</kw>
        </keywords>
        <abstract><p>This document describes the motivation for, and benefits of, applying Segment Routing (SR) in BGP-based large-scale data centers.  It describes the design to deploy SR in those data centers for both the MPLS and IPv6 data planes.</p></abstract>
        <draft>draft-ietf-spring-segment-routing-msdc-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC8670</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8671</doc-id>
        <title>Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)</title>
        <author>
            <name>T. Evens</name>
        </author>
        <author>
            <name>S. Bayraktar</name>
        </author>
        <author>
            <name>P. Lucente</name>
        </author>
        <author>
            <name>P. Mi</name>
        </author>
        <author>
            <name>S. Zhuang</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>adj-rib-out</kw>
        </keywords>
        <abstract><p>The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs).  This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs.  It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.</p></abstract>
        <draft>draft-ietf-grow-bmp-adj-rib-out-07</draft>
        <updates>
            <doc-id>RFC7854</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9736</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC8671</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8672</doc-id>
        <title>TLS Server Identity Pinning with Tickets</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <date>
            <month>October</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>transport layer security</kw>
        </keywords>
        <abstract><p>Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.</p><p> This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.</p></abstract>
        <draft>draft-sheffer-tls-pinning-ticket-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8672</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8673</doc-id>
        <title>HTTP Random Access and Live Content</title>
        <author>
            <name>C. Pratt</name>
        </author>
        <author>
            <name>D. Thakore</name>
        </author>
        <author>
            <name>B. Stark</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>http</kw>
            <kw>range</kw>
            <kw>unit</kw>
            <kw>live</kw>
            <kw>aggregation</kw>
        </keywords>
        <abstract><p>To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.</p></abstract>
        <draft>draft-ietf-httpbis-rand-access-live-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8673</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8674</doc-id>
        <title>The "safe" HTTP Preference</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>safe</kw>
            <kw>preference</kw>
            <kw>child-protection</kw>
        </keywords>
        <abstract><p>This specification defines a preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server.</p><p> This specification does not define a precise semantic for "safe". Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.</p><p> Support for this preference by clients and servers is optional.</p></abstract>
        <draft>draft-nottingham-safe-hint-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8674</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8675</doc-id>
        <title>A YANG Data Model for Tunnel Interface Types</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>softwire</kw>
            <kw>Augment tunnel</kw>
            <kw>tunnel management</kw>
            <kw>tunnel provisioning</kw>
            <kw>tunnel activation</kw>
            <kw>tunnel automation</kw>
        </keywords>
        <abstract><p>This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.</p><p> Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.</p><p> Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.</p></abstract>
        <draft>draft-ietf-softwire-iftunnel-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8675</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8676</doc-id>
        <title>YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires</title>
        <author>
            <name>I. Farrer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>A+P</kw>
            <kw>address sharing</kw>
            <kw>port set</kw>
            <kw>Port range</kw>
            <kw>IPv4 service continuity</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
            <kw>Programmability</kw>
            <kw>Dynamic provisioning</kw>
            <kw>automation</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.</p></abstract>
        <draft>draft-ietf-softwire-yang-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>softwire</wg_acronym>
        <doi>10.17487/RFC8676</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8677</doc-id>
        <title>Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework</title>
        <author>
            <name>D. Trossen</name>
        </author>
        <author>
            <name>D. Purkayastha</name>
        </author>
        <author>
            <name>A. Rahman</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>service function</kw>
            <kw>SF</kw>
            <kw>SFF</kw>
            <kw>nSFF</kw>
            <kw>SFC</kw>
            <kw>SFP</kw>
            <kw>NSH</kw>
            <kw>FQDN</kw>
            <kw>5G</kw>
            <kw>NSSAI</kw>
            <kw>CCNF</kw>
            <kw>NSSF</kw>
            <kw>3GPP</kw>
        </keywords>
        <abstract><p>Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.</p><p> This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.</p></abstract>
        <draft>draft-trossen-sfc-name-based-sff-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8678</doc-id>
        <title>Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.</p><p> This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies. It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.</p></abstract>
        <draft>draft-ietf-rtgwg-enterprise-pa-multihoming-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8678</errata-url>
        <doi>10.17487/RFC8678</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8679</doc-id>
        <title>MPLS Egress Protection Framework</title>
        <author>
            <name>Y. Shen</name>
        </author>
        <author>
            <name>M. Jeganathan</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>C. Michel</name>
        </author>
        <author>
            <name>H. Chen</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>fast reroute</kw>
            <kw>egress protection</kw>
            <kw>local repair</kw>
        </keywords>
        <abstract><p>This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures.  For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector.  It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector.  The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.</p></abstract>
        <draft>draft-ietf-mpls-egress-protection-framework-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8679</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8680</doc-id>
        <title>Forward Error Correction (FEC) Framework Extension to Sliding Window Codes</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>A. Begen</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>FECFRAME</kw>
            <kw>packet loss recovery</kw>
            <kw>RLC</kw>
            <kw>Sliding Window FEC Codes</kw>
        </keywords>
        <abstract><p>RFC 6363 describes a framework for using Forward Error Correction (FEC) codes to provide protection against packet loss.  The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media.  However, FECFRAME as per RFC 6363 is restricted to block FEC codes.  This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way.  During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.</p></abstract>
        <draft>draft-ietf-tsvwg-fecframe-ext-08</draft>
        <updates>
            <doc-id>RFC6363</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8681</doc-id>
        <title>Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME</title>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>B. Teibi</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>RLC</kw>
            <kw>FEC</kw>
            <kw>FECFRAME</kw>
            <kw>packet loss recovery</kw>
            <kw>reliability</kw>
        </keywords>
        <abstract><p>This document describes two fully specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois Field (a.k.a., Finite Field) GF(2), a second one for RLC over the Galois Field GF(2^8), each time with the possibility of controlling the code density.  They can protect arbitrary media streams along the lines defined by FECFRAME extended to Sliding Window FEC Codes.  These Sliding Window FEC Codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed.  Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages with real-time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities.</p></abstract>
        <draft>draft-ietf-tsvwg-rlc-fec-scheme-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8681</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8682</doc-id>
        <title>TinyMT32 Pseudorandom Number Generator (PRNG)</title>
        <author>
            <name>M. Saito</name>
        </author>
        <author>
            <name>M. Matsumoto</name>
        </author>
        <author>
            <name>V. Roca</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Baccelli</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document describes the TinyMT32 Pseudorandom Number Generator (PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution.  This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG.  The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller Linear Congruential PRNG.  However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications.</p></abstract>
        <draft>draft-ietf-tsvwg-tinymt32-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8682</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8683</doc-id>
        <title>Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks</title>
        <author>
            <name>J. Palet Martinez</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>DNSSEC</kw>
            <kw>NAT64</kw>
            <kw>DNS64</kw>
            <kw>464XLAT</kw>
            <kw>CLAT</kw>
            <kw>NAT46</kw>
            <kw>PLAT</kw>
        </keywords>
        <abstract><p>This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations.  This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications.</p></abstract>
        <draft>draft-ietf-v6ops-nat64-deployment-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8683</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8684</doc-id>
        <title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
        <author>
            <name>A. Ford</name>
        </author>
        <author>
            <name>C. Raiciu</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <author>
            <name>C. Paasch</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>tcp</kw>
            <kw>extensions</kw>
            <kw>multipath</kw>
            <kw>multihomed</kw>
            <kw>subflow</kw>
        </keywords>
        <abstract><p>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.</p><p> Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.</p><p> This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.</p></abstract>
        <draft>draft-ietf-mptcp-rfc6824bis-18</draft>
        <obsoletes>
            <doc-id>RFC6824</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>mptcp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8684</errata-url>
        <doi>10.17487/RFC8684</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8685</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture</title>
        <author>
            <name>F. Zhang</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>R. Casellas</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>Traffic Engineering</kw>
            <kw>Inter-domain</kw>
            <kw>Multi-domain</kw>
        </keywords>
        <abstract><p>The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.</p><p> This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures.</p></abstract>
        <draft>draft-ietf-pce-hierarchy-extensions-11</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8685</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8686</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery</title>
        <author>
            <name>S. Kiesel</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Application-Layer Traffic Optimization (ALTO)</kw>
            <kw>ALTO cross-domain server discovery</kw>
            <kw>ALTO third-party server discovery</kw>
        </keywords>
        <abstract><p>The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers that can provide suitable guidance.</p><p> In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.</p><p> Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix.</p></abstract>
        <draft>draft-ietf-alto-xdom-disc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC8686</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8687</doc-id>
        <title>OSPF Routing with Cross-Address Family Traffic Engineering Tunnels</title>
        <author>
            <name>A. Smirnov</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>TE</kw>
            <kw>MPLS</kw>
        </keywords>
        <abstract><p>When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Path (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross-address family (X-AF) OSPF TE information.</p><p> This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses.</p></abstract>
        <draft>draft-ietf-ospf-xaf-te-07</draft>
        <updates>
            <doc-id>RFC5786</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8687</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8688</doc-id>
        <title>A Session Initiation Protocol (SIP) Response Code for Rejected Calls</title>
        <author>
            <name>E.W. Burger</name>
        </author>
        <author>
            <name>B. Nagda</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>STIR</kw>
            <kw>SIPCORE</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document defines the 608 (Rejected) Session Initiation Protocol (SIP) response code.  This response code enables calling parties to learn that an intermediary rejected their call attempt.  No one will deliver, and thus answer, the call.  As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail.  The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine.  In this case, the rejection is by a machine or other process.  This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call.  In some jurisdictions, this distinction is important.  This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error.  This provides a remediation mechanism for legal callers that find their calls blocked.</p></abstract>
        <draft>draft-ietf-sipcore-rejected-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8688</errata-url>
        <doi>10.17487/RFC8688</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8689</doc-id>
        <title>SMTP Require TLS Option</title>
        <author>
            <name>J. Fenton</name>
        </author>
        <date>
            <month>November</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SMTP</kw>
        </keywords>
        <abstract><p>The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security.  This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required.  If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based Authentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant.</p></abstract>
        <draft>draft-ietf-uta-smtp-require-tls-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8689</errata-url>
        <doi>10.17487/RFC8689</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8690</doc-id>
        <title>Clarification of Segment ID Sub-TLV Length for RFC 8287</title>
        <author>
            <name>N. Nainar</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>F. Iqbal</name>
        </author>
        <author>
            <name>A. Vainshtein</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>mpls</kw>
        </keywords>
        <abstract><p>RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.</p><p> This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.</p></abstract>
        <draft>draft-ietf-mpls-rfc8287-len-clarification-04</draft>
        <updates>
            <doc-id>RFC8287</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8690</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8691</doc-id>
        <title>Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11</title>
        <author>
            <name>N. Benamar</name>
        </author>
        <author>
            <name>J. Härri</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>T. Ernst</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>IPv6 over 802.11p</kw>
            <kw>OCB</kw>
            <kw>IPv6 over 802.11-OCB</kw>
        </keywords>
        <abstract><p>This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link.  Support for these methods and settings require minimal changes to existing stacks.  This document also describes limitations associated with using these methods.  Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work.</p></abstract>
        <draft>draft-ietf-ipwave-ipv6-over-80211ocb-52</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipwave</wg_acronym>
        <doi>10.17487/RFC8691</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8692</doc-id>
        <title>Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs</title>
        <author>
            <name>P. Kampanakis</name>
        </author>
        <author>
            <name>Q. Dang</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SHAKE in X.509</kw>
            <kw>SHAKEs in PKIX</kw>
            <kw>certificates with SHAKE hashes</kw>
        </keywords>
        <abstract><p>Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs).  This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms.  The conventions for the associated subject public keys are also described.</p></abstract>
        <draft>draft-ietf-lamps-pkix-shake-15</draft>
        <updates>
            <doc-id>RFC3279</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8692</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8693</doc-id>
        <title>OAuth 2.0 Token Exchange</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>A. Nadalin</name>
        </author>
        <author>
            <name>B. Campbell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>C. Mortimore</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>Delegation</kw>
            <kw>Impersonation</kw>
            <kw>STS</kw>
            <kw>Security Token Service</kw>
            <kw>Exchange</kw>
            <kw>Token</kw>
            <kw>OAuth</kw>
        </keywords>
        <abstract><p>This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</p></abstract>
        <draft>draft-ietf-oauth-token-exchange-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8693</errata-url>
        <doi>10.17487/RFC8693</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8694</doc-id>
        <title>Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>D. King</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.</p><p> This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks.</p></abstract>
        <draft>draft-ietf-pce-inter-area-as-applicability-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8694</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8695</doc-id>
        <title>A YANG Data Model for the Routing Information Protocol (RIP)</title>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>P. Sarda</name>
        </author>
        <author>
            <name>V. Choudhary</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>RIP</kw>
            <kw>RIPng</kw>
            <kw>data model</kw>
            <kw>ietf-rip</kw>
            <kw>network management</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).</p><p> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-rtgwg-yang-rip-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC8695</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8696</doc-id>
        <title>Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>quantum-resistant</kw>
        </keywords>
        <abstract><p>The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today.  The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer.  By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available.  Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them.  This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.</p></abstract>
        <draft>draft-ietf-lamps-cms-mix-with-psk-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8696</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8697</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)</title>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>E. Crabbe</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>H. Ananthakrishnan</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Y. Tanaka</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>PCEP</kw>
            <kw>Association</kw>
            <kw>Group</kw>
        </keywords>
        <abstract><p>This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE).  This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.</p></abstract>
        <draft>draft-ietf-pce-association-group-10</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8697</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8698</doc-id>
        <title>Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media</title>
        <author>
            <name>X. Zhu</name>
        </author>
        <author>
            <name>R. Pan</name>
        </author>
        <author>
            <name>M. Ramalho</name>
        </author>
        <author>
            <name>S. Mena</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Multimedia</kw>
            <kw>Congestion Control</kw>
        </keywords>
        <abstract><p>This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing.  In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach.  The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes.  It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead.</p></abstract>
        <draft>draft-ietf-rmcat-nada-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8698</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8699</doc-id>
        <title>Coupled Congestion Control for RTP Media</title>
        <author>
            <name>S. Islam</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>S. Gjessing</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>tcp</kw>
        </keywords>
        <abstract><p>When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness.  This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications.  This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms.</p></abstract>
        <draft>draft-ietf-rmcat-coupled-cc-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8699</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8700</doc-id>
        <title>Fifty Years of RFCs</title>
        <author>
            <name>H. Flanagan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2019</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>History</kw>
            <kw>RFC Series</kw>
            <kw>Retrospective</kw>
        </keywords>
        <abstract><p>This RFC marks the fiftieth anniversary for the RFC Series.  It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs.  It concludes with thoughts on possibilities for the next fifty years for the Series.  This document updates the perspectives offered in RFCs 2555 and 5540.</p></abstract>
        <draft>draft-iab-fiftyyears-01</draft>
        <updates>
            <doc-id>RFC2555</doc-id>
            <doc-id>RFC5540</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8700</errata-url>
        <doi>10.17487/RFC8700</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8701</doc-id>
        <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title>
        <author>
            <name>D. Benjamin</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>GREASE</kw>
        </keywords>
        <abstract><p>This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem.  It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.</p></abstract>
        <draft>draft-ietf-tls-grease-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC8701</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8702</doc-id>
        <title>Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>P. Kampanakis</name>
        </author>
        <author>
            <name>Q. Dang</name>
        </author>
        <date>
            <month>January</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>SHAKEs in CMS</kw>
            <kw>SHAKE</kw>
            <kw>CMS with SHAKEs</kw>
        </keywords>
        <abstract><p>This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA).  The conventions for the associated signer public keys in CMS are also described.</p></abstract>
        <draft>draft-ietf-lamps-cms-shakes-18</draft>
        <updates>
            <doc-id>RFC3370</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8702</errata-url>
        <doi>10.17487/RFC8702</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8703</doc-id>
        <title>Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension</title>
        <author>
            <name>R. Taylor</name>
        </author>
        <author>
            <name>S. Ratliff</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>DLEP</kw>
            <kw>MANET</kw>
            <kw>Link-Aware</kw>
            <kw>Radio-Aware</kw>
        </keywords>
        <abstract><p>The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC 8175) assumes that every modem in the radio network has an attached DLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.</p><p> This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain.</p></abstract>
        <draft>draft-ietf-manet-dlep-lid-extension-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8703</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8704</doc-id>
        <title>Enhanced Feasible-Path Unicast Reverse Path Forwarding</title>
        <author>
            <name>K. Sriram</name>
        </author>
        <author>
            <name>D. Montgomery</name>
        </author>
        <author>
            <name>J. Haas</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>source address spoofing</kw>
            <kw>source address validation</kw>
            <kw>SAV</kw>
            <kw>Reverse Path Forwarding</kw>
            <kw>RPF</kw>
            <kw>unicast RPF</kw>
            <kw>uRPF</kw>
            <kw>DDoS mitigation</kw>
            <kw>BCP 38</kw>
            <kw>BCP 84</kw>
        </keywords>
        <abstract><p>This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38).  Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704).  However, as shown in this document, the existing feasible-path uRPF still has shortcomings.  This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704).  The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV).  Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques.  This document updates RFC 3704.</p></abstract>
        <draft>draft-ietf-opsec-urpf-improvements-04</draft>
        <updates>
            <doc-id>RFC3704</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>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC8704</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8705</doc-id>
        <title>OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>N. Sakimura</name>
        </author>
        <author>
            <name>T. Lodderstedt</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>MTLS</kw>
            <kw>Mutual TLS</kw>
            <kw>proof-of-possession</kw>
            <kw>proof-of-possession access token</kw>
            <kw>key confirmed access token</kw>
            <kw>certificate-bound access token</kw>
            <kw>client certificate</kw>
            <kw>X.509 Client Certificate Authentication</kw>
            <kw>key confirmation</kw>
            <kw>confirmation method</kw>
            <kw>holder-of-key</kw>
            <kw>OAuth</kw>
        </keywords>
        <abstract><p>This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates.  OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI).  OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.</p></abstract>
        <draft>draft-ietf-oauth-mtls-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC8705</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8706</doc-id>
        <title>Restart Signaling for IS-IS</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>P. Wells</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>graceful restart</kw>
        </keywords>
        <abstract><p>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.</p><p> This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.</p><p> This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.</p><p> This document obsoletes RFC 5306.</p></abstract>
        <draft>draft-ietf-lsr-isis-rfc5306bis-09</draft>
        <obsoletes>
            <doc-id>RFC5306</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8706</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8707</doc-id>
        <title>Resource Indicators for OAuth 2.0</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>Resource</kw>
            <kw>Audience</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.</p></abstract>
        <draft>draft-ietf-oauth-resource-indicators-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8707</errata-url>
        <doi>10.17487/RFC8707</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8708</doc-id>
        <title>Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>digital signature</kw>
            <kw>message content</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS).  In addition, the algorithm identifier and public key syntax are provided.  The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.</p></abstract>
        <draft>draft-ietf-lamps-cms-hash-sig-10</draft>
        <obsoleted-by>
            <doc-id>RFC9708</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8708</errata-url>
        <doi>10.17487/RFC8708</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8709</doc-id>
        <title>Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol</title>
        <author>
            <name>B. Harris</name>
        </author>
        <author>
            <name>L. Velvindron</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol.  Accordingly, this RFC updates RFC 4253.</p></abstract>
        <draft>draft-ietf-curdle-ssh-ed25519-ed448-11</draft>
        <updates>
            <doc-id>RFC4253</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8709</errata-url>
        <doi>10.17487/RFC8709</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8710</doc-id>
        <title>Multipart Content-Format for the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>T. Fossati</name>
        </author>
        <author>
            <name>K. Hartke</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>Multipart Content-Format</kw>
        </keywords>
        <abstract><p>This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.</p></abstract>
        <draft>draft-ietf-core-multipart-ct-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8710</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8711</doc-id>
        <title>Structure of the IETF Administrative Support Activity, Version 2.0</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>J. Hall</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>IASA</kw>
            <kw>IASA2</kw>
        </keywords>
        <abstract><p>The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.</p><p> This document obsoletes RFC 4071, RFC 4333, and RFC 7691.</p></abstract>
        <draft>draft-ietf-iasa2-rfc4071bis-11</draft>
        <obsoletes>
            <doc-id>RFC4071</doc-id>
            <doc-id>RFC4333</doc-id>
            <doc-id>RFC7691</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0101</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <doi>10.17487/RFC8711</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8712</doc-id>
        <title>The IETF-ISOC Relationship</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>J. Livingood</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IASA</kw>
        </keywords>
        <abstract><p>This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018.  The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure.  As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.</p></abstract>
        <draft>draft-ietf-iasa2-rfc2031bis-08</draft>
        <obsoletes>
            <doc-id>RFC2031</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <doi>10.17487/RFC8712</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8713</doc-id>
        <title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Hinden</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Livingood</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IASA</kw>
            <kw>IASA 2.0</kw>
            <kw>IASA2</kw>
        </keywords>
        <abstract><p>The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.</p><p> This document obsoletes RFC 7437 and RFC 8318.</p></abstract>
        <draft>draft-ietf-iasa2-rfc7437bis-09</draft>
        <obsoletes>
            <doc-id>RFC7437</doc-id>
            <doc-id>RFC8318</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9389</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0010</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8713</errata-url>
        <doi>10.17487/RFC8713</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8714</doc-id>
        <title>Update to the Process for Selection of Trustees for the IETF Trust</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.</p><p> This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.</p></abstract>
        <draft>draft-ietf-iasa2-trust-update-03</draft>
        <obsoletes>
            <doc-id>RFC4371</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0101</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8714</errata-url>
        <doi>10.17487/RFC8714</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8715</doc-id>
        <title>IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IETF administration</kw>
            <kw>intellectual property</kw>
            <kw>leadership selection</kw>
            <kw>IASA</kw>
        </keywords>
        <abstract><p>This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust".</p><p> At the time RFC 8714 was published, the changes to the IETF Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update.</p></abstract>
        <draft>draft-ietf-iasa2-trust-rationale-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <doi>10.17487/RFC8715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8716</doc-id>
        <title>Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Harassment</kw>
            <kw>Ombudsteam</kw>
            <kw>IAOC</kw>
            <kw>IETF Administration LLC</kw>
        </keywords>
        <abstract><p>The IETF Anti-Harassment Procedures are described in RFC 7776.</p><p> The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.</p><p> RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.</p></abstract>
        <draft>draft-ietf-iasa2-rfc7776bis-03</draft>
        <updates>
            <doc-id>RFC7776</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0025</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <doi>10.17487/RFC8716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8717</doc-id>
        <title>IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology</title>
        <author>
            <name>J. Klensin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IASA</kw>
            <kw>IASA2</kw>
        </keywords>
        <abstract><p>In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure.  In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere.  Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.</p></abstract>
        <draft>draft-ietf-iasa2-consolidated-upd-07</draft>
        <updates>
            <doc-id>RFC2028</doc-id>
            <doc-id>RFC2418</doc-id>
            <doc-id>RFC3005</doc-id>
            <doc-id>RFC3710</doc-id>
            <doc-id>RFC3929</doc-id>
            <doc-id>RFC4633</doc-id>
            <doc-id>RFC6702</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0101</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8717</errata-url>
        <doi>10.17487/RFC8717</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8718</doc-id>
        <title>IETF Plenary Meeting Venue Selection Process</title>
        <author>
            <name>E. Lear</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Meeting Venues</kw>
            <kw>Meeting selection process</kw>
            <kw>IASA</kw>
        </keywords>
        <abstract><p>The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue.  This memo specifies IETF community requirements for meeting venues, including hotels and meeting space.  It also directs the IASA to make available additional process documents that describe the current meeting selection process.</p></abstract>
        <draft>draft-ietf-mtgvenue-iaoc-venue-selection-process-16</draft>
        <updated-by>
            <doc-id>RFC9712</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0226</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>mtgvenue</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8718</errata-url>
        <doi>10.17487/RFC8718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8719</doc-id>
        <title>High-Level Guidance for the Meeting Policy of the IETF</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>geographic distribution location</kw>
            <kw>IASA</kw>
        </keywords>
        <abstract><p>This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.</p></abstract>
        <draft>draft-ietf-mtgvenue-meeting-policy-07</draft>
        <updated-by>
            <doc-id>RFC9712</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0226</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>mtgvenue</wg_acronym>
        <doi>10.17487/RFC8719</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8720</doc-id>
        <title>Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries</title>
        <author>
            <name>R. Housley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IASA</kw>
        </keywords>
        <abstract><p>This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.</p></abstract>
        <draft>draft-iab-rfc7500-bis-00</draft>
        <obsoletes>
            <doc-id>RFC7500</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8720</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8721</doc-id>
        <title>Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents</title>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IASA</kw>
            <kw>Trust</kw>
        </keywords>
        <abstract><p>Contributors grant intellectual property rights to the IETF.  The IETF Trust holds and manages those rights on behalf of the IETF.  The Trustees of the IETF Trust are responsible for that management.  This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs.  The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted.  This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions.  This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).</p></abstract>
        <draft>draft-ietf-iasa2-rfc5377bis-03</draft>
        <obsoletes>
            <doc-id>RFC5377</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>iasa2</wg_acronym>
        <doi>10.17487/RFC8721</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8722</doc-id>
        <title>Defining the Role and Function of IETF Protocol Parameter Registry Operators</title>
        <author>
            <name>D. McPherson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Klensin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Huston</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>Governance</kw>
        </keywords>
        <abstract><p>Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets.  To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined.  The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions.  For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity.  This document provides a description of, and the requirements for, these delegated functions.  This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.</p></abstract>
        <draft>draft-ietf-iasa2-rfc6220bis-04</draft>
        <obsoletes>
            <doc-id>RFC6220</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8722</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8723</doc-id>
        <title>Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>A.B. Roach</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>PERC</kw>
            <kw>SRTP</kw>
            <kw>RTP</kw>
            <kw>conferencing</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees.  This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees.  Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.</p></abstract>
        <draft>draft-ietf-perc-double-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>perc</wg_acronym>
        <doi>10.17487/RFC8723</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8724</doc-id>
        <title>SCHC: Generic Framework for Static Context Header Compression and Fragmentation</title>
        <author>
            <name>A. Minaburo</name>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>D. Barthel</name>
        </author>
        <author>
            <name>JC. Zuniga</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>header compression</kw>
            <kw>compression</kw>
            <kw>fragmentation</kw>
            <kw>static context</kw>
            <kw>rule-based</kw>
            <kw>LPWAN</kw>
            <kw>LPWANs</kw>
            <kw>low power</kw>
            <kw>low-power</kw>
            <kw>6LoWPAN</kw>
            <kw>6lo</kw>
            <kw>LoWPAN</kw>
            <kw>LoWPANs</kw>
            <kw>LLN</kw>
            <kw>LLNs</kw>
            <kw>LTN</kw>
            <kw>LTE</kw>
            <kw>LTE-M</kw>
            <kw>Sigfox</kw>
            <kw>LoRaWAN</kw>
            <kw>NB-IOT</kw>
            <kw>5G</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>adaptation layer</kw>
            <kw>UDP</kw>
            <kw>IPv6</kw>
            <kw>WSN</kw>
            <kw>Sensor network</kw>
            <kw>wireless sensor network</kw>
            <kw>802.15.4</kw>
            <kw>contrained network</kw>
            <kw>constrained node</kw>
            <kw>constrained-node network</kw>
        </keywords>
        <abstract><p>This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.</p><p> SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.</p><p> This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.</p><p> The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.</p></abstract>
        <draft>draft-ietf-lpwan-ipv6-static-context-hc-24</draft>
        <updated-by>
            <doc-id>RFC9441</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC8724</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8725</doc-id>
        <title>JSON Web Token Best Current Practices</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>D. Hardt</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>JSON Object Signing and Encryption</kw>
            <kw>JOSE</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
            <kw>attacks</kw>
            <kw>Claims</kw>
            <kw>Security</kw>
            <kw>Cryptography</kw>
        </keywords>
        <abstract><p>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted.  JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas.  This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</p></abstract>
        <draft>draft-ietf-oauth-jwt-bcp-07</draft>
        <updates>
            <doc-id>RFC7519</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0225</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC8725</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8726</doc-id>
        <title>How Requests for IANA Action Will Be Handled on the Independent Stream</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IANA</kw>
            <kw>Independent Submissions Stream</kw>
            <kw>ISE</kw>
        </keywords>
        <abstract><p>The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.</p><p> The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE).</p><p> This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submission Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.</p></abstract>
        <draft>draft-ise-iana-policy-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8726</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8727</doc-id>
        <title>JSON Binding of the Incident Object Description Exchange Format</title>
        <author>
            <name>T. Takahashi</name>
        </author>
        <author>
            <name>R. Danyliw</name>
        </author>
        <author>
            <name>M. Suzuki</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>88</page-count>
        <keywords>
            <kw>CBOR</kw>
            <kw>JSON</kw>
            <kw>IODEF</kw>
        </keywords>
        <abstract><p>The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information.  This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).</p></abstract>
        <draft>draft-ietf-mile-jsoniodef-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mile</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8727</errata-url>
        <doi>10.17487/RFC8727</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8728</doc-id>
        <title>RFC Editor Model (Version 2)</title>
        <author>
            <name>O. Kolkman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Hinden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IAB</kw>
            <kw>IASA</kw>
            <kw>RSOC</kw>
            <kw>RSE</kw>
            <kw>IASA</kw>
            <kw>IASA2</kw>
        </keywords>
        <abstract><p>The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher.  Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC.  This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.</p></abstract>
        <draft>draft-ietf-iasa2-rfc6635bis-04</draft>
        <obsoletes>
            <doc-id>RFC6635</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9280</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8728</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8729</doc-id>
        <title>The RFC Series and RFC Editor</title>
        <author>
            <name>R. Housley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>IASA</kw>
            <kw>IASA2</kw>
            <kw>technical publisher</kw>
        </keywords>
        <abstract><p>This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate.  This document obsoletes RFC 4844.</p></abstract>
        <draft>draft-ietf-iasa2-rfc4844-bis-05</draft>
        <obsoletes>
            <doc-id>RFC4844</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9280</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8730</doc-id>
        <title>Independent Submission Editor Model</title>
        <author>
            <name>N. Brownlee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Hinden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ISE</kw>
            <kw>RSE</kw>
            <kw>LLC</kw>
            <kw>IAB</kw>
            <kw>IASA</kw>
        </keywords>
        <abstract><p>This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).</p><p> This version obsoletes RFC 6548 to replace all references to the Internet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure.</p></abstract>
        <draft>draft-ietf-iasa2-rfc6548bis-02</draft>
        <obsoletes>
            <doc-id>RFC6548</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9280</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8730</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8731</doc-id>
        <title>Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448</title>
        <author>
            <name>A. Adamantiadis</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>M. Baushke</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Elliptic</kw>
            <kw>Curve</kw>
            <kw>Diffie</kw>
            <kw>Hellman</kw>
            <kw>ECDH</kw>
        </keywords>
        <abstract><p>This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.</p></abstract>
        <draft>draft-ietf-curdle-ssh-curves-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8731</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8732</doc-id>
        <title>Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2</title>
        <author>
            <name>S. Sorce</name>
        </author>
        <author>
            <name>H. Kario</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SSH</kw>
        </keywords>
        <abstract><p>This document specifies additions and amendments to RFC 4462.  It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups.  The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges.</p></abstract>
        <draft>draft-ietf-curdle-gss-keyex-sha2-10</draft>
        <updates>
            <doc-id>RFC4462</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8732</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8733</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE</title>
        <author>
            <name>D. Dhody</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>U. Palle</name>
        </author>
        <author>
            <name>R. Singh</name>
        </author>
        <author>
            <name>L. Fang</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>Bandwidth optimization</kw>
            <kw>PCEP Overwhelm</kw>
            <kw>LSP re-optimization</kw>
        </keywords>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.</p><p> The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-auto-bandwidth-12</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8734</doc-id>
        <title>Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3</title>
        <author>
            <name>L. Bruckert</name>
        </author>
        <author>
            <name>J. Merkle</name>
        </author>
        <author>
            <name>M. Lochter</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>Elliptic Curve Cryptography</kw>
        </keywords>
        <abstract><p>Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS 1.3.</p><p> This document provides the necessary protocol mechanisms for using ECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF.</p></abstract>
        <draft>draft-bruckert-brainpool-for-tls13-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8734</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8735</doc-id>
        <title>Scenarios and Simulation Results of PCE in a Native IP Network</title>
        <author>
            <name>A. Wang</name>
        </author>
        <author>
            <name>X. Huang</name>
        </author>
        <author>
            <name>C. Kou</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>P. Mi</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>CCDR</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.</p><p> One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.</p></abstract>
        <draft>draft-ietf-teas-native-ip-scenarios-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8735</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8736</doc-id>
        <title>PIM Message Type Space Extension and Reserved Bits</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.</p><p> This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.</p><p> This document obsoletes RFC 6166.</p></abstract>
        <draft>draft-ietf-pim-reserved-bits-04</draft>
        <obsoletes>
            <doc-id>RFC6166</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC9436</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3973</doc-id>
            <doc-id>RFC5015</doc-id>
            <doc-id>RFC5059</doc-id>
            <doc-id>RFC6754</doc-id>
            <doc-id>RFC7761</doc-id>
            <doc-id>RFC8364</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC8736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8737</doc-id>
        <title>Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension</title>
        <author>
            <name>R.B. Shoemaker</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>acme</kw>
            <kw>pki</kw>
        </keywords>
        <abstract><p>This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.</p></abstract>
        <draft>draft-ietf-acme-tls-alpn-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC8737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8738</doc-id>
        <title>Automated Certificate Management Environment (ACME) IP Identifier Validation Extension</title>
        <author>
            <name>R.B. Shoemaker</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.</p></abstract>
        <draft>draft-ietf-acme-ip-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC8738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8739</doc-id>
        <title>Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>A. Pastor Perales</name>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>OCSP</kw>
            <kw>CRL</kw>
            <kw>revocation</kw>
        </keywords>
        <abstract><p>Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity.  However, the revocation process is often unreliable.  An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise.  This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.</p></abstract>
        <draft>draft-ietf-acme-star-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC8739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8740</doc-id>
        <title>Using TLS 1.3 with HTTP/2</title>
        <author>
            <name>D. Benjamin</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>renegotiation</kw>
            <kw>post-handshake client authentication</kw>
        </keywords>
        <abstract><p>This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.</p></abstract>
        <draft>draft-ietf-httpbis-http2-tls13-03</draft>
        <obsoleted-by>
            <doc-id>RFC9113</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC7540</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8740</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8741</doc-id>
        <title>Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)</title>
        <author>
            <name>A. Raghuram</name>
        </author>
        <author>
            <name>A. Goddard</name>
        </author>
        <author>
            <name>J. Karthik</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>M. Negi</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.</p><p> There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.</p><p> This document describes an extension to the Path Computation Element Communication Protocol (PCEP) to enable a PCE to make requests for such control.</p></abstract>
        <draft>draft-ietf-pce-lsp-control-request-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8742</doc-id>
        <title>Concise Binary Object Representation (CBOR) Sequences</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.</p><p> Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.</p></abstract>
        <draft>draft-ietf-cbor-sequence-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC8742</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8743</doc-id>
        <title>Multiple Access Management Services Multi-Access Management Services (MAMS)</title>
        <author>
            <name>S. Kanugovi</name>
        </author>
        <author>
            <name>F. Baboescu</name>
        </author>
        <author>
            <name>J. Zhu</name>
        </author>
        <author>
            <name>S. Seo</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>143</page-count>
        <keywords>
            <kw>Integration</kw>
            <kw>Aggregation</kw>
            <kw>Switching</kw>
            <kw>MPTCP</kw>
            <kw>MPQUIC</kw>
            <kw>GMA</kw>
            <kw>5G</kw>
            <kw>LTE</kw>
            <kw>Wi-Fi</kw>
            <kw>Ethernet</kw>
            <kw>Edge</kw>
            <kw>Proxy</kw>
        </keywords>
        <abstract><p>In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.</p><p> This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.</p><p> This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.</p></abstract>
        <draft>draft-kanugovi-intarea-mams-framework-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8743</errata-url>
        <doi>10.17487/RFC8743</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8744</doc-id>
        <title>Issues and Requirements for Server Name Identification (SNI) Encryption in TLS</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.</p><p> In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.</p></abstract>
        <draft>draft-ietf-tls-sni-encryption-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC8744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8745</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE</title>
        <author>
            <name>H. Ananthakrishnan</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>C. Barth</name>
        </author>
        <author>
            <name>I. Minei</name>
        </author>
        <author>
            <name>M. Negi</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>PCEP</kw>
        </keywords>
        <abstract><p>An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs).  Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs.  This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.</p></abstract>
        <draft>draft-ietf-pce-stateful-path-protection-11</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8746</doc-id>
        <title>Concise Binary Object Representation (CBOR) Tags for Typed Arrays</title>
        <author>
            <name>C. Bormann</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR), as defined in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.</p><p> This document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined.</p></abstract>
        <draft>draft-ietf-cbor-array-tags-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC8746</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8747</doc-id>
        <title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>L. Seitz</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>S. Erdtman</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>CBOR Web Token</kw>
            <kw>CWT</kw>
            <kw> Proof-of-Possession</kw>
            <kw>Holder-of-Key</kw>
        </keywords>
        <abstract><p>This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key.  Being able to prove possession of a key is also sometimes described as being the holder-of-key.  This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</p></abstract>
        <draft>draft-ietf-ace-cwt-proof-of-possession-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC8747</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8748</doc-id>
        <title>Registry Fee Extension for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>R. Carney</name>
        </author>
        <author>
            <name>G. Brown</name>
        </author>
        <author>
            <name>J. Frakes</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method for Extensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects.  This document describes an EPP extension mapping for registry fees.</p></abstract>
        <draft>draft-ietf-regext-epp-fees-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8748</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8749</doc-id>
        <title>Moving DNSSEC Lookaside Validation (DLV) to Historic Status</title>
        <author>
            <name>W. Mekking</name>
        </author>
        <author>
            <name>D. Mahoney</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>DLV</kw>
        </keywords>
        <abstract><p>This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic.  Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.</p></abstract>
        <draft>draft-ietf-dnsop-obsolete-dlv-02</draft>
        <updates>
            <doc-id>RFC6698</doc-id>
            <doc-id>RFC6840</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8750</doc-id>
        <title>Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)</title>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>T. Guggemos</name>
        </author>
        <author>
            <name>Y. Nir</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IPsec</kw>
            <kw>GCM</kw>
            <kw>CCM</kw>
            <kw>ChaCha20</kw>
        </keywords>
        <abstract><p>Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet.  The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written.  When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting.  This IV must be unique but can be predictable.  As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce.  This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305.  This document describes how to do this.</p></abstract>
        <draft>draft-ietf-ipsecme-implicit-iv-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8750</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8751</doc-id>
        <title>Hierarchical Stateful Path Computation Element (PCE)</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>J. Shin</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.</p><p> The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.</p><p> Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.</p></abstract>
        <draft>draft-ietf-pce-stateful-hpce-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8751</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8752</doc-id>
        <title>Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>web</kw>
            <kw>security</kw>
            <kw>origin</kw>
            <kw>packaging</kw>
            <kw>bundle</kw>
        </keywords>
        <abstract><p>The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-escape-report-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8753</doc-id>
        <title>Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>P. Fältström</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IDNA2008</kw>
            <kw>IDN</kw>
            <kw>Unicode Algorithmic Review</kw>
            <kw>Unicode Code Point Review</kw>
            <kw>IDNA Designated Expert</kw>
        </keywords>
        <abstract><p>The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward.  That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past.  This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved.  It also makes other minor adjustments to align that document with experience.</p></abstract>
        <draft>draft-klensin-idna-unicode-review-05</draft>
        <updates>
            <doc-id>RFC5892</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8753</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8754</doc-id>
        <title>IPv6 Segment Routing Header (SRH)</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Dukes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>J. Leddy</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>SRv6</kw>
            <kw>source-routing</kw>
            <kw>network-programming</kw>
        </keywords>
        <abstract><p>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).  This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</p></abstract>
        <draft>draft-ietf-6man-segment-routing-header-26</draft>
        <updated-by>
            <doc-id>RFC9800</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8754</errata-url>
        <doi>10.17487/RFC8754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8755</doc-id>
        <title>Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions</title>
        <author>
            <name>M. Jenkins</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NSA</kw>
            <kw>CNSA</kw>
            <kw>NSS</kw>
            <kw>smime</kw>
        </keywords>
        <abstract><p>The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications.  This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551.  It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging.  US National Security Systems are described in NIST Special Publication 800-59.  It is also appropriate for all other US Government systems that process high-value information.  It is made publicly available for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-jenkins-cnsa-smime-profile-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8755</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8756</doc-id>
        <title>Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS</title>
        <author>
            <name>M. Jenkins</name>
        </author>
        <author>
            <name>L. Zieglar</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NSA</kw>
            <kw>CNSA</kw>
            <kw>NSS</kw>
            <kw>certificate</kw>
            <kw>enrollment</kw>
        </keywords>
        <abstract><p>This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government.</p><p> The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.</p><p> The profile is made publicly available here for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-jenkins-cnsa-cmc-profile-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8756</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8757</doc-id>
        <title>Dynamic Link Exchange Protocol (DLEP) Latency Range Extension</title>
        <author>
            <name>B. Cheng</name>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>MANET</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the range of latency that can be experienced on a link.</p></abstract>
        <draft>draft-ietf-manet-dlep-latency-extension-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>manet</wg_acronym>
        <doi>10.17487/RFC8757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8758</doc-id>
        <title>Deprecating RC4 in Secure Shell (SSH)</title>
        <author>
            <name>L. Velvindron</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document deprecates RC4 in Secure Shell (SSH).  Therefore, this document formally moves RFC 4345 to Historic status.</p></abstract>
        <draft>draft-ietf-curdle-rc4-die-die-die-18</draft>
        <updates>
            <doc-id>RFC4253</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0227</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <doi>10.17487/RFC8758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8759</doc-id>
        <title>RTP Payload for Timed Text Markup Language (TTML)</title>
        <author>
            <name>J. Sandford</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>subtitles</kw>
            <kw>captions</kw>
            <kw>imsc</kw>
            <kw>media</kw>
            <kw>streaming</kw>
            <kw>sdp</kw>
            <kw>xml</kw>
        </keywords>
        <abstract><p>This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C.  This payload format is specifically targeted at streaming workflows using TTML.</p></abstract>
        <draft>draft-ietf-payload-rtp-ttml-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8759</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8760</doc-id>
        <title>The Session Initiation Protocol (SIP) Digest Access Authentication Scheme</title>
        <author>
            <name>R. Shekh-Yusef</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Digest Auth</kw>
        </keywords>
        <abstract><p>This document updates RFC 3261 by modifying the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm.</p></abstract>
        <draft>draft-ietf-sipcore-digest-scheme-15</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8760</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8761</doc-id>
        <title>Video Codec Requirements and Evaluation Methodology</title>
        <author>
            <name>A. Filippov</name>
        </author>
        <author>
            <name>A. Norkin</name>
        </author>
        <author>
            <name>J.R. Alvarez</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>NETVC</kw>
            <kw>evaluation</kw>
            <kw>requirements</kw>
            <kw>compression performance</kw>
            <kw>video coding applications</kw>
        </keywords>
        <abstract><p>This document provides requirements for a video codec designed mainly for use over the Internet.  In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.</p></abstract>
        <draft>draft-ietf-netvc-requirements-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>netvc</wg_acronym>
        <doi>10.17487/RFC8761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8762</doc-id>
        <title>Simple Two-Way Active Measurement Protocol</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>G. Jun</name>
        </author>
        <author>
            <name>H. Nydell</name>
        </author>
        <author>
            <name>R. Foote</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.</p></abstract>
        <draft>draft-ietf-ippm-stamp-10</draft>
        <updated-by>
            <doc-id>RFC8972</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8762</errata-url>
        <doi>10.17487/RFC8762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8763</doc-id>
        <title>Deployment Considerations for Information-Centric Networking (ICN)</title>
        <author>
            <name>A. Rahman</name>
        </author>
        <author>
            <name>D. Trossen</name>
        </author>
        <author>
            <name>D. Kutscher</name>
        </author>
        <author>
            <name>R. Ravindran</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>Content Delivery Network (CDN)</kw>
            <kw>overlay</kw>
            <kw>underlay</kw>
            <kw>virtual</kw>
            <kw>virtualization</kw>
            <kw>naming</kw>
            <kw>NFV</kw>
            <kw>SDN</kw>
        </keywords>
        <abstract><p>Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation.  This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments.  First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches.  Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration.  Next, selected ICN trial experiences are summarized.  Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-deployment-guidelines-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8764</doc-id>
        <title>Apple's DNS Long-Lived Queries Protocol</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>M. Krochmal</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Async</kw>
            <kw>Asynchronous</kw>
            <kw>Change Notification</kw>
            <kw>Push Notification</kw>
        </keywords>
        <abstract><p>Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement.</p><p> The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications.</p></abstract>
        <draft>draft-sekar-dns-llq-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8764</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8765</doc-id>
        <title>DNS Push Notifications</title>
        <author>
            <name>T. Pusateri</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>dns</kw>
            <kw>update</kw>
            <kw>push</kw>
            <kw>notification</kw>
        </keywords>
        <abstract><p>The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static.  When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high.  But, there exists no mechanism for a client to be asynchronously notified when these changes occur.  This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications.</p></abstract>
        <draft>draft-ietf-dnssd-push-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC8765</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8766</doc-id>
        <title>Discovery Proxy for Multicast DNS-Based Service Discovery</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Multicast DNS</kw>
            <kw>DNS-Based Service Discovery</kw>
        </keywords>
        <abstract><p>This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link.</p></abstract>
        <draft>draft-ietf-dnssd-hybrid-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC8766</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8767</doc-id>
        <title>Serving Stale Data to Improve DNS Resiliency</title>
        <author>
            <name>D. Lawrence</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>P. Sood</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DDoS</kw>
            <kw>Resiliency</kw>
            <kw>Denial-of-Service</kw>
            <kw>Expired</kw>
        </keywords>
        <abstract><p>This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data.  One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector.  This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.</p></abstract>
        <draft>draft-ietf-dnsop-serve-stale-10</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC2181</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8768</doc-id>
        <title>Constrained Application Protocol (CoAP) Hop-Limit Option</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>J. Shallow</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>security</kw>
            <kw>mitigation</kw>
            <kw>service delivery</kw>
            <kw>connectivity</kw>
            <kw>anti-DDoS</kw>
            <kw>automation</kw>
            <kw>cooperation</kw>
            <kw>Resilience</kw>
            <kw>Filtering</kw>
            <kw>Security Center</kw>
            <kw>Mitigator</kw>
            <kw>Scrubbing</kw>
            <kw>dynamic service protection</kw>
            <kw>dynamic mitigation</kw>
        </keywords>
        <abstract><p>The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable.  To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.</p></abstract>
        <draft>draft-ietf-core-hop-limit-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8768</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8769</doc-id>
        <title>Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding.  The Cryptographic Message Syntax (CMS) is still a widely used method of doing message-based security.  This document defines a set of content types for CMS that hold CBOR content.</p></abstract>
        <draft>draft-schaad-cbor-content-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8770</doc-id>
        <title>Host Router Support for OSPFv2</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <author>
            <name>M. Bhardwaj</name>
        </author>
        <author>
            <name>S. Bayraktar</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>non-transit</kw>
        </keywords>
        <abstract><p>The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path.  This document defines a bit called the Host-bit (H-bit).  This bit enables a router to advertise that it is a non-transit router.  This document also describes the changes needed to support the H-bit in the domain.  In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.</p></abstract>
        <draft>draft-ietf-ospf-ospfv2-hbit-12</draft>
        <updates>
            <doc-id>RFC6987</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8770</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8771</doc-id>
        <title>The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)</title>
        <author>
            <name>A. Mayrhofer</name>
        </author>
        <author>
            <name>J. Hague</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Domain Names were designed for humans, IP addresses were not.  But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses.  This memo describes the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.</p></abstract>
        <draft>draft-mayrhofer-i-dunno-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8771</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8772</doc-id>
        <title>The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)</title>
        <author>
            <name>S. Hu</name>
        </author>
        <author>
            <name>D. Eastlake</name>
        </author>
        <author>
            <name>F. Qin</name>
        </author>
        <author>
            <name>T. Chua</name>
        </author>
        <author>
            <name>D. Huang</name>
        </author>
        <date>
            <month>May</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>124</page-count>
        <keywords>
            <kw>CUPS</kw>
            <kw>CUSP</kw>
            <kw>BRAS</kw>
            <kw>BBRAS</kw>
        </keywords>
        <abstract><p>A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP). China Mobile, Huawei Technologies, and ZTE have developed a simple CUPS control channel protocol to support such communication: the Simple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.</p><p> This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability.</p></abstract>
        <draft>draft-chz-simple-cu-separation-bng-protocol-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8772</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8773</doc-id>
        <title>TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>March</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK).</p></abstract>
        <draft>draft-ietf-tls-tls13-cert-with-extern-psk-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8773</errata-url>
        <doi>10.17487/RFC8773</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8774</doc-id>
        <title>The Quantum Bug</title>
        <author>
            <name>M. Welzl</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Teleportation</kw>
            <kw>Entanglement</kw>
            <kw>0-RTT</kw>
        </keywords>
        <abstract><p>The age of quantum networking is upon us, and with it comes "entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers.  This will lead to a perceived round-trip time of zero seconds on some Internet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications.  Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.</p></abstract>
        <draft>draft-welzl-quantumbug-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8774</errata-url>
        <doi>10.17487/RFC8774</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8775</doc-id>
        <title>PIM Designated Router Load Balancing</title>
        <author>
            <name>Y. Cai</name>
        </author>
        <author>
            <name>H. Ou</name>
        </author>
        <author>
            <name>S. Vallepalli</name>
        </author>
        <author>
            <name>M. Mishra</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>A. Green</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router.  One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM.  This document specifies a modification to the PIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.</p></abstract>
        <draft>draft-ietf-pim-drlb-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC8775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8776</doc-id>
        <title>Common YANG Data Types for Traffic Engineering</title>
        <author>
            <name>T. Saad</name>
        </author>
        <author>
            <name>R. Gandhi</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <author>
            <name>I. Bryskin</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>TE Tunnel</kw>
            <kw>TE Model</kw>
            <kw>TE Types</kw>
            <kw>TE YANG</kw>
            <kw>TE Topology</kw>
            <kw>TE Interfaces</kw>
            <kw>TE LSP Model</kw>
        </keywords>
        <abstract><p>This document defines a collection of common data types and groupings in YANG data modeling language.  These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.</p></abstract>
        <draft>draft-ietf-teas-yang-te-types-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8776</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8777</doc-id>
        <title>DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery</title>
        <author>
            <name>J. Holland</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>DRIAD</kw>
            <kw>DRYAD</kw>
            <kw>AMT</kw>
            <kw>IGMPv3</kw>
            <kw>MLDv2</kw>
            <kw>SSM</kw>
            <kw>amt gateway</kw>
            <kw>amt relay</kw>
            <kw>multicast</kw>
            <kw>multicast replication</kw>
            <kw>multicast encapsulation</kw>
            <kw>amt relay discovery</kw>
            <kw>amt discovery</kw>
            <kw>AMTRELAY</kw>
        </keywords>
        <abstract><p>This document updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by modifying the relay discovery process.  A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels.  The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel.  Other extensions and clarifications to the relay discovery process are also defined.</p></abstract>
        <draft>draft-ietf-mboned-driad-amt-discovery-13</draft>
        <updates>
            <doc-id>RFC7450</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8777</errata-url>
        <doi>10.17487/RFC8777</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8778</doc-id>
        <title>Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>digital signature</kw>
            <kw>HSS/LMS Hash-based Signature Algorithm</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax.  The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.</p></abstract>
        <draft>draft-ietf-cose-hash-sig-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC8778</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8779</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS</title>
        <author>
            <name>C. Margaria</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Zhang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>RSVP-TE</kw>
            <kw>GMPLS</kw>
            <kw>PCE</kw>
        </keywords>
        <abstract><p>A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025.</p><p> This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.</p></abstract>
        <draft>draft-ietf-pce-gmpls-pcep-extensions-16</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8779</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8780</doc-id>
        <title>The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Casellas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Wavelength Allocation</kw>
            <kw>Transparent Optical Networks</kw>
            <kw>Fixed DWDM Grid</kw>
        </keywords>
        <abstract><p>This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs).  Path provisioning in WSONs requires an RWA process.  From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.</p></abstract>
        <draft>draft-ietf-pce-wson-rwa-ext-17</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8780</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8781</doc-id>
        <title>Discovering PREF64 in Router Advertisements</title>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <date>
            <month>April</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.</p></abstract>
        <draft>draft-ietf-6man-ra-pref64-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8781</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8782</doc-id>
        <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
        <author>
            <name>T. Reddy.K</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Patil</name>
        </author>
        <author>
            <name>A. Mortensen</name>
        </author>
        <author>
            <name>N. Teague</name>
        </author>
        <date>
            <month>May</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>100</page-count>
        <keywords>
            <kw>security</kw>
            <kw>mitigation</kw>
            <kw>service delivery</kw>
            <kw>connectivity</kw>
            <kw>anti-DDoS</kw>
            <kw>automation</kw>
            <kw>cooperation</kw>
            <kw>resilience</kw>
            <kw>filtering</kw>
            <kw>security center</kw>
            <kw>mitigator</kw>
            <kw>scrubbing</kw>
            <kw>dynamic service protection</kw>
            <kw>dynamic mitigation</kw>
            <kw>cooperative networking</kw>
            <kw>protective networking</kw>
        </keywords>
        <abstract><p>This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.</p><p> A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.</p></abstract>
        <draft>draft-ietf-dots-signal-channel-41</draft>
        <obsoleted-by>
            <doc-id>RFC9132</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8782</errata-url>
        <doi>10.17487/RFC8782</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8783</doc-id>
        <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Reddy.K</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>DOTS</kw>
            <kw>Automation</kw>
            <kw>Security</kw>
            <kw>Mitigation</kw>
            <kw>Scrubbing</kw>
            <kw>Anti-DDoS</kw>
            <kw>Mitigator</kw>
            <kw>Security Center</kw>
            <kw>Filtering</kw>
            <kw>Resilience</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.</p><p> This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).</p></abstract>
        <draft>draft-ietf-dots-data-channel-31</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8783</errata-url>
        <doi>10.17487/RFC8783</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8784</doc-id>
        <title>Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security</title>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <author>
            <name>P. Kampanakis</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>internet key exchange</kw>
            <kw>quantum computer</kw>
            <kw>post quantum</kw>
            <kw>post-quantum</kw>
            <kw>quantum safe</kw>
            <kw>quantum secure</kw>
            <kw>quantum resistant</kw>
        </keywords>
        <abstract><p>The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today.  The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available.  It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term.  To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.</p></abstract>
        <draft>draft-ietf-ipsecme-qr-ikev2-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8784</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8785</doc-id>
        <title>JSON Canonicalization Scheme (JCS)</title>
        <author>
            <name>A. Rundgren</name>
        </author>
        <author>
            <name>B. Jordan</name>
        </author>
        <author>
            <name>S. Erdtman</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>ECMAScript</kw>
            <kw>Signatures</kw>
            <kw>Cryptography</kw>
            <kw>Canonicalization</kw>
        </keywords>
        <abstract><p>Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.</p><p> This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.</p></abstract>
        <draft>draft-rundgren-json-canonicalization-scheme-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8785</errata-url>
        <doi>10.17487/RFC8785</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8786</doc-id>
        <title>Updated Rules for Processing Stateful PCE Request Parameters Flags</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>May</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>PCEP</kw>
            <kw>Path Computation Element</kw>
            <kw>Stateful PCE</kw>
            <kw>Flags</kw>
        </keywords>
        <abstract><p>Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.</p><p> This document updates RFC 8231 by defining the correct behaviors.</p></abstract>
        <draft>draft-ietf-pce-stateful-flags-01</draft>
        <updates>
            <doc-id>RFC8231</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8786</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8787</doc-id>
        <title>Location Source Parameter for the SIP Geolocation Header Field</title>
        <author>
            <name>J. Winterbottom</name>
        </author>
        <author>
            <name>R. Jesske</name>
        </author>
        <author>
            <name>B. Chatras</name>
        </author>
        <author>
            <name>A. Hutton</name>
        </author>
        <date>
            <month>May</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>Emergency</kw>
            <kw>Call</kw>
            <kw>Location</kw>
        </keywords>
        <abstract><p>There are some circumstances where a Geolocation header field may contain more than one locationValue.  Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues.  This document defines the "loc-src" parameter so that the entity adding the locationValue to the Geolocation header field can identify itself using its hostname.  This document updates RFC 6442.</p></abstract>
        <draft>draft-ietf-sipcore-locparam-06</draft>
        <updates>
            <doc-id>RFC6442</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC8787</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8788</doc-id>
        <title>Eligibility for the 2020-2021 Nominating Committee</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>May</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>nomcom</kw>
        </keywords>
        <abstract><p>The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification.  This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting.  This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.</p></abstract>
        <draft>draft-iesg-nomcom-eligibility-2020-03</draft>
        <obsoleted-by>
            <doc-id>RFC9389</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8788</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8789</doc-id>
        <title>IETF Stream Documents Require IETF Rough Consensus</title>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Rescorla</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>process</kw>
            <kw>publication</kw>
        </keywords>
        <abstract><p>This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus.  This updates RFC 2026.</p></abstract>
        <draft>draft-halpern-gendispatch-consensusinformational-04</draft>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8789</errata-url>
        <doi>10.17487/RFC8789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8790</doc-id>
        <title>FETCH and PATCH with Sensor Measurement Lists (SenML)</title>
        <author>
            <name>A. Keränen</name>
        </author>
        <author>
            <name>M. Mohajer</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>IoT</kw>
            <kw>data model</kw>
        </keywords>
        <abstract><p>The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters.  The Constrained Application Protocol (CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request.  This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.</p></abstract>
        <draft>draft-ietf-core-senml-etch-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8791</doc-id>
        <title>YANG Data Structure Extensions</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>M. Björklund</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes YANG mechanisms for defining abstract data structures with YANG.</p></abstract>
        <draft>draft-ietf-netmod-yang-data-ext-05</draft>
        <updates>
            <doc-id>RFC8340</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8791</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8792</doc-id>
        <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>E. Auerswald</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>sourcecode</kw>
            <kw>artwork</kw>
        </keywords>
        <abstract><p>This document defines two strategies for handling long lines in width-bounded text content.  One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line.  The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy.  Both strategies use a self-describing header enabling automated reconstitution of the original content.</p></abstract>
        <draft>draft-ietf-netmod-artwork-folding-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8792</errata-url>
        <doi>10.17487/RFC8792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8793</doc-id>
        <title>Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology</title>
        <author>
            <name>B. Wissingh</name>
        </author>
        <author>
            <name>C. Wood</name>
        </author>
        <author>
            <name>A. Afanasyev</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>C. Tschudin</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>content routing</kw>
            <kw>content caching</kw>
            <kw>content distribution networks</kw>
            <kw>data-centric security</kw>
        </keywords>
        <abstract><p>Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses.  Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures.  This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN.  While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-terminology-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8794</doc-id>
        <title>Extensible Binary Meta Language</title>
        <author>
            <name>S. Lhomme</name>
        </author>
        <author>
            <name>D. Rice</name>
        </author>
        <author>
            <name>M. Bunkus</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>cellar</kw>
            <kw>binary</kw>
            <kw>storage</kw>
            <kw>xml</kw>
            <kw>matroska</kw>
            <kw>webm</kw>
            <kw>ebml</kw>
        </keywords>
        <abstract><p>This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage.  EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values.  Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document.</p></abstract>
        <draft>draft-ietf-cellar-ebml-17</draft>
        <updated-by>
            <doc-id>RFC9559</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cellar</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8794</errata-url>
        <doi>10.17487/RFC8794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8795</doc-id>
        <title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <author>
            <name>T. Saad</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>170</page-count>
        <keywords>
            <kw>TE topology</kw>
            <kw>TE topology YANG model</kw>
            <kw>Abstract TE topology</kw>
            <kw>Native TE topology</kw>
            <kw>Customized TE topology</kw>
            <kw>Underlay TE topology</kw>
            <kw>Overlay TE topology</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies.  The model serves as a base model that other technology-specific TE topology models can augment.</p></abstract>
        <draft>draft-ietf-teas-yang-te-topo-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8796</doc-id>
        <title>RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels</title>
        <author>
            <name>M. Taillon</name>
        </author>
        <author>
            <name>T. Saad</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gandhi</name>
        </author>
        <author>
            <name>A. Deshmukh</name>
        </author>
        <author>
            <name>M. Jork</name>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document updates RFC 4090 for the Resource Reservation Protocol (RSVP) Traffic Engineering (TE) procedures defined for facility backup protection.  The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute (FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved.  These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the number of protected Label Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used.  The signaling extensions are fully backwards compatible with nodes that do not support them.</p></abstract>
        <draft>draft-ietf-mpls-summary-frr-rsvpte-09</draft>
        <updates>
            <doc-id>RFC4090</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8796</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8797</doc-id>
        <title>Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1</title>
        <author>
            <name>C. Lever</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>NFS-over-RDMA</kw>
        </keywords>
        <abstract><p>This document specifies the format of Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection.  The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol.  This document updates RFC 8166.</p></abstract>
        <draft>draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08</draft>
        <updates>
            <doc-id>RFC8166</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC8797</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8798</doc-id>
        <title>Additional Units for Sensor Measurement Lists (SenML)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Internet of Things (IoT)</kw>
            <kw>data model</kw>
            <kw>quantities and units</kw>
            <kw>International System of Units (SI)</kw>
            <kw>International System of Quantities (ISQ)</kw>
        </keywords>
        <abstract><p>The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented.  This short document registers a number of additional unit names in the IANA registry for units in SenML.  It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.</p></abstract>
        <draft>draft-ietf-core-senml-more-units-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8798</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8799</doc-id>
        <title>Limited Domains and Internet Protocols</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>B. Liu</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.</p><p> This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.</p></abstract>
        <draft>draft-carpenter-limited-domains-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8799</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8800</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>C. Barth</name>
        </author>
        <author>
            <name>M. Negi</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Disjoint</kw>
            <kw>disjointness</kw>
            <kw>association</kw>
        </keywords>
        <abstract><p>This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs.  The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.</p></abstract>
        <draft>draft-ietf-pce-association-diversity-15</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8800</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8801</doc-id>
        <title>Discovering Provisioning Domain Names and Data</title>
        <author>
            <name>P. Pfister</name>
        </author>
        <author>
            <name>É. Vyncke</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>W. Shao</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Provisioning</kw>
            <kw>DHCP</kw>
            <kw>PvD</kw>
        </keywords>
        <abstract><p>Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.</p><p> This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.</p></abstract>
        <draft>draft-ietf-intarea-provisioning-domains-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC8801</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8802</doc-id>
        <title>The Quality for Service (Q4S) Protocol</title>
        <author>
            <name>J.J. Aranda</name>
        </author>
        <author>
            <name>M. Cortes</name>
        </author>
        <author>
            <name>J. Salvachúa</name>
        </author>
        <author>
            <name>M. Narganes</name>
        </author>
        <author>
            <name>I. Martínez-Sarriegui</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>quality measurement</kw>
            <kw>measurement protocol</kw>
            <kw>latency</kw>
            <kw>jitter</kw>
            <kw>bandwidth</kw>
            <kw>packet-loss</kw>
        </keywords>
        <abstract><p>This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on the HyperText Transfer Protocol (HTTP) and the Session Description Protocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.</p><p> Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).</p><p> This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus.</p></abstract>
        <draft>draft-aranda-dispatch-q4s-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8802</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8803</doc-id>
        <title>0-RTT TCP Convert Protocol</title>
        <author>
            <name>O. Bonaventure</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Gundavelli</name>
        </author>
        <author>
            <name>S. Seo</name>
        </author>
        <author>
            <name>B. Hesmans</name>
        </author>
        <date>
            <month>July</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>Hybrid access</kw>
            <kw>aggregation</kw>
            <kw>transport evolution</kw>
            <kw>future internet</kw>
            <kw>extension</kw>
            <kw>Trafic Steering</kw>
            <kw>ATSSS</kw>
            <kw>Multipath TCP</kw>
        </keywords>
        <abstract><p>This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).</p><p> This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).</p><p> This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP.</p></abstract>
        <draft>draft-ietf-tcpm-converters-19</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC8803</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8804</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Request Routing Extensions</title>
        <author>
            <name>O. Finkelman</name>
        </author>
        <author>
            <name>S. Mishra</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN).  This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint &amp; Capabilities Advertisement interface (FCI).  These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.</p></abstract>
        <draft>draft-ietf-cdni-request-routing-extensions-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC8804</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8805</doc-id>
        <title>A Format for Self-Published IP Geolocation Feeds</title>
        <author>
            <name>E. Kline</name>
        </author>
        <author>
            <name>K. Duleba</name>
        </author>
        <author>
            <name>Z. Szamonek</name>
        </author>
        <author>
            <name>S. Moser</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>geo-location</kw>
            <kw>geolocation</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract><p>This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.</p><p> Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.</p><p> This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.</p></abstract>
        <draft>draft-google-self-published-geofeeds-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8805</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8806</doc-id>
        <title>Running a Root Server Local to a Resolver</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>local-root</kw>
        </keywords>
        <abstract><p>Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.</p><p> This document obsoletes RFC 7706.</p></abstract>
        <draft>draft-ietf-dnsop-7706bis-12</draft>
        <obsoletes>
            <doc-id>RFC7706</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8806</errata-url>
        <doi>10.17487/RFC8806</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8807</doc-id>
        <title>Login Security Extension for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>M. Pozun</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password.  The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password.  This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.</p></abstract>
        <draft>draft-ietf-regext-login-security-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8807</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8808</doc-id>
        <title>A YANG Data Model for Factory Default Settings</title>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>B. Lengyel</name>
        </author>
        <author>
            <name>Y. Niu</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.</p><p> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p></abstract>
        <draft>draft-ietf-netmod-factory-default-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8808</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8809</doc-id>
        <title>Registries for Web Authentication (WebAuthn)</title>
        <author>
            <name>J. Hodges</name>
        </author>
        <author>
            <name>G. Mandyam</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>webauthn</kw>
            <kw>attestation</kw>
            <kw>extensions</kw>
            <kw>registry</kw>
        </keywords>
        <abstract><p>This specification defines IANA registries for W3C Web Authentication (WebAuthn) attestation statement format identifiers and extension identifiers.</p></abstract>
        <draft>draft-hodges-webauthn-registries-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8809</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8810</doc-id>
        <title>Revision to Capability Codes Registration Procedures</title>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IDR</kw>
        </keywords>
        <abstract><p>This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes.  Specifically, the range formerly designated "Private Use" is divided into three new ranges: "First Come First Served", "Experimental Use", and "Reserved".</p></abstract>
        <draft>draft-ietf-idr-capabilities-registry-change-09</draft>
        <updates>
            <doc-id>RFC5492</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8810</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8811</doc-id>
        <title>DDoS Open Threat Signaling (DOTS) Architecture</title>
        <author>
            <name>A. Mortensen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Reddy.K</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>N. Teague</name>
        </author>
        <author>
            <name>R. Compton</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains.  The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.</p></abstract>
        <draft>draft-ietf-dots-architecture-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC8811</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8812</doc-id>
        <title>CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms</title>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Cryptography</kw>
            <kw>Digital Signature</kw>
            <kw>Encryption</kw>
            <kw>W3C</kw>
            <kw>World Wide Web Consortium</kw>
            <kw>WebAuthn</kw>
            <kw>Web Authentication</kw>
            <kw>FIDO Alliance</kw>
            <kw>FIDO</kw>
            <kw>FIDO2</kw>
            <kw>CTAP</kw>
            <kw>CTAP2</kw>
        </keywords>
        <abstract><p>The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers.  This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256.  It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry.  Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.</p></abstract>
        <draft>draft-ietf-cose-webauthn-algorithms-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC8812</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8813</doc-id>
        <title>Clarifications for Elliptic Curve Cryptography Subject Public Key Information</title>
        <author>
            <name>T. Ito</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>X.509</kw>
            <kw>ECC</kw>
        </keywords>
        <abstract><p>This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography.</p></abstract>
        <draft>draft-ietf-lamps-5480-ku-clarifications-03</draft>
        <updates>
            <doc-id>RFC5480</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8813</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8814</doc-id>
        <title>Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State</title>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>U. Chunduri</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>N. Triantafillis</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>SID</kw>
            <kw>MSD</kw>
            <kw>SR</kw>
        </keywords>
        <abstract><p>This document defines a way for a Border Gateway Protocol - Link
State (BGP-LS) speaker to advertise multiple types of supported
Maximum SID Depths (MSDs) at node and/or link granularity.</p><p> Such advertisements allow entities (e.g., centralized controllers) to
determine whether a particular Segment Identifier (SID) stack can be
supported in a given network.</p></abstract>
        <draft>draft-ietf-idr-bgp-ls-segment-routing-msd-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC8814</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8815</doc-id>
        <title>Deprecating Any-Source Multicast (ASM) for Interdomain Multicast</title>
        <author>
            <name>M. Abrahamsson</name>
        </author>
        <author>
            <name>T. Chown</name>
        </author>
        <author>
            <name>L. Giuliano</name>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ASM</kw>
            <kw>Deprecate</kw>
            <kw>Deprecation</kw>
            <kw>Interdomain</kw>
            <kw>Intradomain</kw>
            <kw>PIM-SM</kw>
            <kw>PIM-SSM</kw>
            <kw> SSM</kw>
            <kw>MSDP</kw>
            <kw>MBONE</kw>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast.  It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM.  The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).</p></abstract>
        <draft>draft-ietf-mboned-deprecate-interdomain-asm-07</draft>
        <is-also>
            <doc-id>BCP0229</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC8815</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8816</doc-id>
        <title>Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers.  However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end.  This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.</p></abstract>
        <draft>draft-ietf-stir-oob-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC8816</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8817</doc-id>
        <title>RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec</title>
        <author>
            <name>V. Demjanenko</name>
        </author>
        <author>
            <name>J. Punaro</name>
        </author>
        <author>
            <name>D. Satterlee</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>MELP</kw>
            <kw>MELPe</kw>
            <kw>TSVCIS</kw>
            <kw>NRLVDR</kw>
            <kw>Naval Research Laboratory</kw>
            <kw>NRL</kw>
            <kw>NATO</kw>
            <kw>TSVWG</kw>
            <kw>Department of Defense</kw>
            <kw>DoD</kw>
            <kw>NSA</kw>
            <kw>MIL-STD</kw>
        </keywords>
        <abstract><p>This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder.  TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks.  It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality.  TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation Linear Prediction (MELP) 2400 speech data.  The RTP packetization of TSVCIS and MELPe speech coder data is described in detail.</p></abstract>
        <draft>draft-ietf-payload-tsvcis-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8817</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8818</doc-id>
        <title>Distributed Mobility Anchoring</title>
        <author>
            <name>H. Chan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Wei</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>S. Jeon</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>anchor</kw>
            <kw>address continuity</kw>
            <kw>reachability</kw>
            <kw>continuity</kw>
            <kw>PMIPv6</kw>
            <kw>MIPv6</kw>
        </keywords>
        <abstract><p>This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support.  A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs.  In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor.  To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network.  If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility.  This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.</p></abstract>
        <draft>draft-ietf-dmm-distributed-mobility-anchoring-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8819</doc-id>
        <title>YANG Module Tags</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Bogdanovic</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>tags</kw>
        </keywords>
        <abstract><p>This document provides for the association of tags with YANG modules.  The expectation is for such tags to be used to help classify and organize modules.  A method for defining, reading, and writing modules tags is provided.  Tags may be registered and assigned during module definition, assigned by implementations, or dynamically defined and set by users.  This document also provides guidance to future model writers; as such, this document updates RFC 8407.</p></abstract>
        <draft>draft-ietf-netmod-module-tags-10</draft>
        <updates>
            <doc-id>RFC8407</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC8819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8820</doc-id>
        <title>URI Design and Ownership</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>June</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>URI structure</kw>
        </keywords>
        <abstract><p>Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.</p><p> This document provides guidance on the specification of URI substructure in standards.</p><p> This document obsoletes RFC 7320 and updates RFC 3986.</p></abstract>
        <draft>draft-nottingham-rfc7320bis-03</draft>
        <obsoletes>
            <doc-id>RFC7320</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3986</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0190</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8820</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8821</doc-id>
        <title>PCE-Based Traffic Engineering (TE) in Native IP Networks</title>
        <author>
            <name>A. Wang</name>
        </author>
        <author>
            <name>B. Khasanov</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>H. Chen</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Centralized Control Dynamic Routing</kw>
            <kw>CCDR</kw>
        </keywords>
        <abstract><p>This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism.  It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP).</p></abstract>
        <draft>draft-ietf-teas-pce-native-ip-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC8821</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8822</doc-id>
        <title>5G Wireless Wireline Convergence User Plane Encapsulation (5WE)</title>
        <author>
            <name>D. Allan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Eastlake</name>
        </author>
        <author>
            <name>D. Woolley</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>PPPoE</kw>
            <kw>W-AGF</kw>
            <kw>QFI</kw>
            <kw>RQI</kw>
            <kw>WWC</kw>
        </keywords>
        <abstract><p>As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF).  The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding.  It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).</p></abstract>
        <draft>draft-allan-5g-fmc-encapsulation-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8822</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8823</doc-id>
        <title>Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>ACME</kw>
            <kw>S/MIME</kw>
        </keywords>
        <abstract><p>This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.</p></abstract>
        <draft>draft-ietf-acme-email-smime-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8823</errata-url>
        <doi>10.17487/RFC8823</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8824</doc-id>
        <title>Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>A. Minaburo</name>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <author>
            <name>R. Andreasen</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>header compression</kw>
            <kw>fragmentation</kw>
            <kw>IoT</kw>
            <kw>constrained networks</kw>
            <kw>LPWAN</kw>
            <kw>sensor network</kw>
            <kw>constrained node</kw>
            <kw>wireless sensor network</kw>
            <kw>core</kw>
            <kw>OSCORE</kw>
        </keywords>
        <abstract><p>This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework.  SCHC defines a header compression mechanism adapted for Constrained Devices.  SCHC uses a static description of the header to reduce the header's redundancy and size.  While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers.  The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length.  The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages.  This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</p></abstract>
        <draft>draft-ietf-lpwan-coap-static-context-hc-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8824</errata-url>
        <doi>10.17487/RFC8824</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8825</doc-id>
        <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".</p><p> It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track.</p><p> This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC).</p></abstract>
        <draft>draft-ietf-rtcweb-overview-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8826</doc-id>
        <title>Security Considerations for WebRTC</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".  This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.</p></abstract>
        <draft>draft-ietf-rtcweb-security-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8826</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8827</doc-id>
        <title>WebRTC Security Architecture</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".</p></abstract>
        <draft>draft-ietf-rtcweb-security-arch-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8827</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8828</doc-id>
        <title>WebRTC IP Address Handling Requirements</title>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>G. Shieh</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>WebRTC</kw>
            <kw>privacy</kw>
            <kw>private</kw>
            <kw>IP address</kw>
            <kw>routing</kw>
            <kw>proxy</kw>
            <kw>peer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract><p>This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations.</p></abstract>
        <draft>draft-ietf-rtcweb-ip-handling-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8828</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8829</doc-id>
        <title>JavaScript Session Establishment Protocol (JSEP)</title>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>E. Rescorla</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>webrtc</kw>
            <kw>sdp</kw>
            <kw>negotiation</kw>
            <kw>signaling</kw>
            <kw>peerconnection</kw>
            <kw>api</kw>
            <kw>ice</kw>
            <kw>rtp</kw>
            <kw>offer</kw>
            <kw>answer</kw>
        </keywords>
        <abstract><p>This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.</p></abstract>
        <draft>draft-ietf-rtcweb-jsep-26</draft>
        <obsoleted-by>
            <doc-id>RFC9429</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8829</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8830</doc-id>
        <title>WebRTC MediaStream Identification in the Session Description Protocol</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>MediaStreamTrack</kw>
        </keywords>
        <abstract><p>This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.</p><p> This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication (WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling.</p></abstract>
        <draft>draft-ietf-mmusic-msid-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8830</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8831</doc-id>
        <title>WebRTC Data Channels</title>
        <author>
            <name>R. Jesup</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>M. Tüxen</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers.  This document specifies the non-media data transport aspects of the WebRTC framework.  It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer.</p></abstract>
        <draft>draft-ietf-rtcweb-data-channel-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8831</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8832</doc-id>
        <title>WebRTC Data Channel Establishment Protocol</title>
        <author>
            <name>R. Jesup</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>M. Tüxen</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers.  This document specifies a simple protocol for establishing symmetric data channels between the peers.  It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete.</p></abstract>
        <draft>draft-ietf-rtcweb-data-protocol-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8832</errata-url>
        <doi>10.17487/RFC8832</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8833</doc-id>
        <title>Application-Layer Protocol Negotiation (ALPN) for WebRTC</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ALPN</kw>
            <kw>Protocol</kw>
            <kw>Identifier</kw>
        </keywords>
        <abstract><p>This document specifies two Application-Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communication (WebRTC).  The "webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control Transmission Protocol (SCTP) over DTLS.  The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.</p></abstract>
        <draft>draft-ietf-rtcweb-alpn-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8833</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8834</doc-id>
        <title>Media Transport and Use of RTP in WebRTC</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <abstract><p>The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc.  between two peers' web browsers.  This memo describes the media transport aspects of the WebRTC framework.  It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported.</p></abstract>
        <draft>draft-ietf-rtcweb-rtp-usage-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8834</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8835</doc-id>
        <title>Transports for WebRTC</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document describes the data transport protocols used by Web Real-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes.</p></abstract>
        <draft>draft-ietf-rtcweb-transports-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8835</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8836</doc-id>
        <title>Congestion Control Requirements for Interactive Real-Time Media</title>
        <author>
            <name>R. Jesup</name>
        </author>
        <author>
            <name>Z. Sarker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Interactive multimedia</kw>
            <kw>webrtc</kw>
            <kw>video communication</kw>
            <kw>RTP/RTCP</kw>
        </keywords>
        <abstract><p>Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.</p><p> This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique.</p></abstract>
        <draft>draft-ietf-rmcat-cc-requirements-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8836</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8837</doc-id>
        <title>Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>S. Dhesikan</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>D. Druta</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Diffserv</kw>
            <kw>rtcweb</kw>
        </keywords>
        <abstract><p>Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis.  This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-Time Communication (WebRTC) traffic.</p></abstract>
        <draft>draft-ietf-tsvwg-rtcweb-qos-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8837</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8838</doc-id>
        <title>Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol</title>
        <author>
            <name>E. Ivov</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once.  This method can considerably accelerate the process of establishing a communication session.</p></abstract>
        <draft>draft-ietf-ice-trickle-21</draft>
        <updated-by>
            <doc-id>RFC8863</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ice</wg_acronym>
        <doi>10.17487/RFC8838</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8839</doc-id>
        <title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)</title>
        <author>
            <name>M. Petit-Huguenin</name>
        </author>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>A. Keränen</name>
        </author>
        <author>
            <name>R. Shpount</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents.</p><p> This document obsoletes RFCs 5245 and 6336.</p></abstract>
        <draft>draft-ietf-mmusic-ice-sip-sdp-39</draft>
        <obsoletes>
            <doc-id>RFC5245</doc-id>
            <doc-id>RFC6336</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8839</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8840</doc-id>
        <title>A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)</title>
        <author>
            <name>E. Ivov</name>
        </author>
        <author>
            <name>T. Stach</name>
        </author>
        <author>
            <name>E. Marocco</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>ICE</kw>
            <kw>trickle</kw>
            <kw>SIP</kw>
            <kw>SDP</kw>
            <kw>NAT</kw>
        </keywords>
        <abstract><p>The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.</p><p> This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined.</p></abstract>
        <draft>draft-ietf-mmusic-trickle-ice-sip-18</draft>
        <updated-by>
            <doc-id>RFC9725</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8840</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8841</doc-id>
        <title>Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>R. Shpount</name>
        </author>
        <author>
            <name>S. Loreto</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SCTP,SDP,DTLS</kw>
        </keywords>
        <abstract><p>The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.</p><p> This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations.</p></abstract>
        <draft>draft-ietf-mmusic-sctp-sdp-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8841</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8842</doc-id>
        <title>Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>R. Shpount</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>DTLS</kw>
            <kw>tls-id</kw>
        </keywords>
        <abstract><p>This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.</p><p> This document defines a new SDP media-level attribute, "tls-id".</p><p> This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122.</p></abstract>
        <draft>draft-ietf-mmusic-dtls-sdp-32</draft>
        <updates>
            <doc-id>RFC5763</doc-id>
            <doc-id>RFC7345</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9725</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8842</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8843</doc-id>
        <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>SDP</kw>
            <kw>Bundle</kw>
            <kw>Multiplexing</kw>
            <kw>RTCWEB</kw>
            <kw>CLUE</kw>
            <kw>MMUSIC</kw>
            <kw>AVT</kw>
            <kw>WEB</kw>
            <kw>Browser</kw>
        </keywords>
        <abstract><p>This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.</p><p> This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension.</p><p> This specification updates RFCs 3264, 5888, and 7941.</p></abstract>
        <draft>draft-ietf-mmusic-sdp-bundle-negotiation-54</draft>
        <obsoleted-by>
            <doc-id>RFC9143</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3264</doc-id>
            <doc-id>RFC5888</doc-id>
            <doc-id>RFC7941</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8843</errata-url>
        <doi>10.17487/RFC8843</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8844</doc-id>
        <title>Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Unknown Key-Share Attack</kw>
            <kw>SDP</kw>
            <kw>DTLS-SRTP</kw>
            <kw>WebRTC</kw>
            <kw>SIP identity</kw>
        </keywords>
        <abstract><p>This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP).  Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity.  These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer.  This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.</p></abstract>
        <draft>draft-ietf-mmusic-sdp-uks-07</draft>
        <updates>
            <doc-id>RFC8122</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8844</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8845</doc-id>
        <title>Framework for Telepresence Multi-Streams</title>
        <author>
            <name>M. Duckworth</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Pepperell</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>Telepresence</kw>
            <kw>Conferencing</kw>
            <kw>Video-Conferencing</kw>
            <kw>MCU</kw>
        </keywords>
        <abstract><p>This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate.  The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams.  This protocol is used in addition to SIP signaling and Session Description Protocol (SDP) negotiation for setting up a telepresence session.</p></abstract>
        <draft>draft-ietf-clue-framework-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC8845</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8846</doc-id>
        <title>An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model</title>
        <author>
            <name>R. Presta</name>
        </author>
        <author>
            <name>S P. Romano</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>CLUE</kw>
            <kw>Telepresence</kw>
            <kw>Data Model</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>This document provides an XML schema file for the definition of CLUE data model types.  The term "CLUE" stands for "Controlling Multiple Streams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed.  The document defines a coherent structure for information associated with the description of a telepresence scenario.</p></abstract>
        <draft>draft-ietf-clue-data-model-schema-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC8846</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8847</doc-id>
        <title>Protocol for Controlling Multiple Streams for Telepresence (CLUE)</title>
        <author>
            <name>R. Presta</name>
        </author>
        <author>
            <name>S P. Romano</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>Telepresence</kw>
            <kw>Protocol</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol conceived for the description and negotiation of a telepresence session.  The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE Working Group.  A companion document, RFC 8848, delves into CLUE signaling details as well as the SIP / Session Description Protocol (SDP) session establishment phase.  CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" stands for "Stream Control Transmission Protocol".) Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed.</p></abstract>
        <draft>draft-ietf-clue-protocol-19</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC8847</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8848</doc-id>
        <title>Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)</title>
        <author>
            <name>R. Hanton</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <author>
            <name>L. Xiao</name>
        </author>
        <author>
            <name>C. Groves</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document is about Controlling Multiple Streams for Telepresence (CLUE) signaling.  It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the Session Description Protocol (SDP), to produce a telepresence call.</p></abstract>
        <draft>draft-ietf-clue-signaling-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC8848</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8849</doc-id>
        <title>Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures</title>
        <author>
            <name>R. Even</name>
        </author>
        <author>
            <name>J. Lennox</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams for Telepresence (CLUE) protocol.  It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in the Session Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID).</p></abstract>
        <draft>draft-ietf-clue-rtp-mapping-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC8849</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8850</doc-id>
        <title>Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>SDP</kw>
            <kw>DTLS</kw>
            <kw>SCTP</kw>
            <kw>DATA</kw>
            <kw>CHANNEL</kw>
            <kw>DCEP</kw>
            <kw>DATA_CHANNEL_OPEN</kw>
            <kw>DATA_CHANNEL_ACK</kw>
            <kw>PPID</kw>
            <kw>TELEPRESENCE</kw>
            <kw>RTCWEB</kw>
            <kw>WEBRTC</kw>
        </keywords>
        <abstract><p>This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities.</p></abstract>
        <draft>draft-ietf-clue-datachannel-18</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>clue</wg_acronym>
        <doi>10.17487/RFC8850</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8851</doc-id>
        <title>RTP Payload Format Restrictions</title>
        <author>
            <name>A.B. Roach</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <abstract><p>In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol (SDP). This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.</p><p> This specification updates RFC 4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions defined by this document.</p></abstract>
        <draft>draft-ietf-mmusic-rid-15</draft>
        <updates>
            <doc-id>RFC4855</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8851</errata-url>
        <doi>10.17487/RFC8851</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8852</doc-id>
        <title>RTP Stream Identifier Source Description (SDES)</title>
        <author>
            <name>A.B. Roach</name>
        </author>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <author>
            <name>P. Thatcher</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document defines and registers two new Real-time Transport Control Protocol (RTCP) Stream Identifier Source Description (SDES) items.  One, named RtpStreamId, is used for unique identification of RTP streams.  The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream.</p></abstract>
        <draft>draft-ietf-avtext-rid-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC8852</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8853</doc-id>
        <title>Using Simulcast in Session Description Protocol (SDP) and RTP Sessions</title>
        <author>
            <name>B. Burman</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <author>
            <name>M. Zanaty</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams.  This is called simulcast.  This document describes how to accomplish simulcast in RTP and how to signal it in the Session Description Protocol (SDP).  The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source.  The SDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.</p></abstract>
        <draft>draft-ietf-mmusic-sdp-simulcast-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8853</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8854</doc-id>
        <title>WebRTC Forward Error Correction Requirements</title>
        <author>
            <name>J. Uberti</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>FEC</kw>
        </keywords>
        <abstract><p>This document provides information and requirements for the use of Forward Error Correction (FEC) by WebRTC implementations.</p></abstract>
        <draft>draft-ietf-rtcweb-fec-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC8854</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8855</doc-id>
        <title>The Binary Floor Control Protocol (BFCP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>K. Drage</name>
        </author>
        <author>
            <name>T. Kristensen</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>C. Eckel</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>87</page-count>
        <keywords>
            <kw>floor control</kw>
            <kw>conference</kw>
        </keywords>
        <abstract><p>Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.</p><p> This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.</p><p> This document obsoletes RFC 4582.</p></abstract>
        <draft>draft-ietf-bfcpbis-rfc4582bis-16</draft>
        <obsoletes>
            <doc-id>RFC4582</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>bfcpbis</wg_acronym>
        <doi>10.17487/RFC8855</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8856</doc-id>
        <title>Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>T. Kristensen</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>floor control</kw>
            <kw>BFCP</kw>
            <kw>SDP</kw>
        </keywords>
        <abstract><p>This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams.</p><p> This document obsoletes RFC 4583.</p></abstract>
        <draft>draft-ietf-bfcpbis-rfc4583bis-27</draft>
        <obsoletes>
            <doc-id>RFC4583</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>bfcpbis</wg_acronym>
        <doi>10.17487/RFC8856</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8857</doc-id>
        <title>The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)</title>
        <author>
            <name>V. Pascual</name>
        </author>
        <author>
            <name>A. Román</name>
        </author>
        <author>
            <name>S. Cazeaux</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>R. Ravindranath</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BFCP</kw>
            <kw>WebSocket</kw>
        </keywords>
        <abstract><p>The WebSocket protocol enables two-way real-time communication between clients and servers.  This document specifies the use of Binary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios.</p></abstract>
        <draft>draft-ietf-bfcpbis-bfcp-websocket-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>bfcpbis</wg_acronym>
        <doi>10.17487/RFC8857</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8858</doc-id>
        <title>Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>RTCP</kw>
            <kw>SDP</kw>
            <kw>OFFER</kw>
            <kw>ANSWER</kw>
            <kw>MUX</kw>
            <kw> MULTIPLEX</kw>
            <kw>RTCWEB</kw>
            <kw>WebRTC</kw>
            <kw>JSEP</kw>
        </keywords>
        <abstract><p>This document defines a new Session Description Protocol (SDP) media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing.  The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.</p></abstract>
        <draft>draft-ietf-mmusic-mux-exclusive-12</draft>
        <updates>
            <doc-id>RFC5761</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8858</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8859</doc-id>
        <title>A Framework for Session Description Protocol (SDP) Attributes When Multiplexing</title>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>82</page-count>
        <abstract><p>The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions.</p><p> This specification also categorizes the existing SDP attributes based on the framework described herein.</p></abstract>
        <draft>draft-ietf-mmusic-sdp-mux-attributes-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8859</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8860</doc-id>
        <title>Sending Multiple Types of Media in a Single RTP Session</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>J. Lennox</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Real-time</kw>
            <kw>Multiplexing</kw>
            <kw>Bundle</kw>
        </keywords>
        <abstract><p>This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text.  This has been restricted by the RTP specifications (RFCs 3550 and 3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session.</p></abstract>
        <draft>draft-ietf-avtcore-multi-media-rtp-session-13</draft>
        <updates>
            <doc-id>RFC3550</doc-id>
            <doc-id>RFC3551</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8860</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8861</doc-id>
        <title>Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>RGRP</kw>
            <kw>SDES</kw>
            <kw>XR</kw>
            <kw>Reporting</kw>
            <kw>Group</kw>
        </keywords>
        <abstract><p>RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP Control Protocol (RTCP) reception quality reports for every other SSRC visible in the session.  This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints.  In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality.  This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-multi-stream-optimisation-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8861</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8862</doc-id>
        <title>Best Practices for Securing RTP Media Signaled with SIP</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>RTP</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions.  Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model.  This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities.</p></abstract>
        <draft>draft-ietf-sipbrandy-rtpsec-08</draft>
        <is-also>
            <doc-id>BCP0228</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipbrandy</wg_acronym>
        <doi>10.17487/RFC8862</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8863</doc-id>
        <title>Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ICE</kw>
            <kw>PAC</kw>
            <kw>Candidate</kw>
        </keywords>
        <abstract><p>During the process of establishing peer-to-peer connectivity, Interactive Connectivity Establishment (ICE) agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur.</p><p> This document updates RFCs 8445 and 8838 by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check.</p></abstract>
        <draft>draft-ietf-ice-pac-06</draft>
        <updates>
            <doc-id>RFC8445</doc-id>
            <doc-id>RFC8838</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ice</wg_acronym>
        <doi>10.17487/RFC8863</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8864</doc-id>
        <title>Negotiation Data Channels Using the Session Description Protocol (SDP)</title>
        <author>
            <name>K. Drage</name>
        </author>
        <author>
            <name>M. Makaraju</name>
        </author>
        <author>
            <name>R. Ejzak</name>
        </author>
        <author>
            <name>J. Marcon</name>
        </author>
        <author>
            <name>R. Even</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or some out-of-band non-DCEP protocol.  This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel.</p></abstract>
        <draft>draft-ietf-mmusic-data-channel-sdpneg-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8864</errata-url>
        <doi>10.17487/RFC8864</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8865</doc-id>
        <title>T.140 Real-Time Text Conversation over WebRTC Data Channels</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>G. Hellström</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>SDP</kw>
            <kw>ITU-T</kw>
            <kw>T.140</kw>
            <kw>Data Channel</kw>
            <kw>WebRTC</kw>
            <kw>real-time text</kw>
        </keywords>
        <abstract><p>This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel.  This document updates RFC 8373 to specify its use with WebRTC data channels.</p></abstract>
        <draft>draft-ietf-mmusic-t140-usage-data-channel-14</draft>
        <updates>
            <doc-id>RFC8373</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8865</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8866</doc-id>
        <title>SDP: Session Description Protocol</title>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>Multimedia</kw>
            <kw>conferencing</kw>
            <kw>session setup</kw>
            <kw>signaling</kw>
            <kw>media</kw>
            <kw>SIP</kw>
            <kw>RTSP</kw>
            <kw>voip</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>streaming</kw>
        </keywords>
        <abstract><p>This memo 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.  This document obsoletes RFC 4566.</p></abstract>
        <draft>draft-ietf-mmusic-rfc4566bis-37</draft>
        <obsoletes>
            <doc-id>RFC4566</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8866</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8867</doc-id>
        <title>Test Cases for Evaluating Congestion Control for Interactive Real-Time Media</title>
        <author>
            <name>Z. Sarker</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>X. Zhu</name>
        </author>
        <author>
            <name>M. Ramalho</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Multimedia</kw>
            <kw>Test cases</kw>
            <kw>Congestion Control</kw>
        </keywords>
        <abstract><p>The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications.  These applications are typically required to implement congestion control.  This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment.</p></abstract>
        <draft>draft-ietf-rmcat-eval-test-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8867</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8868</doc-id>
        <title>Evaluating Congestion Control for Interactive Real-Time Media</title>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>S. Holmer</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>RTCP</kw>
            <kw>Congestion Control</kw>
        </keywords>
        <abstract><p>The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications.  This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media.</p></abstract>
        <draft>draft-ietf-rmcat-eval-criteria-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8868</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8869</doc-id>
        <title>Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks</title>
        <author>
            <name>Z. Sarker</name>
        </author>
        <author>
            <name>X. Zhu</name>
        </author>
        <author>
            <name>J. Fu</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Cellular Network</kw>
            <kw>Wi-Fi Network</kw>
            <kw>Congestion Control</kw>
            <kw>RTP</kw>
        </keywords>
        <abstract><p>The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications.  The performance of these applications typically depends on a well-functioning congestion control algorithm.  To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types.  This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks.</p></abstract>
        <draft>draft-ietf-rmcat-wireless-tests-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC8869</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8870</doc-id>
        <title>Encrypted Key Transport for DTLS and Secure RTP</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>J. Mattsson</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>PERC</kw>
            <kw>SRTP</kw>
            <kw>RTP</kw>
            <kw>conferencing</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract><p>Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and the Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP.  This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints.</p></abstract>
        <draft>draft-ietf-perc-srtp-ekt-diet-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>perc</wg_acronym>
        <doi>10.17487/RFC8870</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8871</doc-id>
        <title>A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>D. Benham</name>
        </author>
        <author>
            <name>C. Groves</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>PERC</kw>
            <kw>Private Media Framework</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract><p>This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where Media Distributors are not trusted with the end-to-end media encryption keys.  The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP).</p></abstract>
        <draft>draft-ietf-perc-private-media-framework-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>perc</wg_acronym>
        <doi>10.17487/RFC8871</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8872</doc-id>
        <title>Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>B. Burman</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>R. Even</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Simulcast</kw>
        </keywords>
        <abstract><p>The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies.  That flexibility makes for wide applicability but can complicate the application design process.  One particular design question that has received much attention is how to support multiple media streams in RTP.  This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams.</p></abstract>
        <draft>draft-ietf-avtcore-multiplex-guidelines-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC8872</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8873</doc-id>
        <title>Message Session Relay Protocol (MSRP) over Data Channels</title>
        <author>
            <name>JM. Recio</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>webrtc</kw>
        </keywords>
        <abstract><p>This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the Message Session Relay Protocol (MSRP) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel.  Two network configurations are supported: the connection of two MSRP data channel endpoints; and a gateway configuration, which connects an MSRP data channel endpoint with an MSRP endpoint that uses either TCP or TLS.  This document updates RFC 4975.</p></abstract>
        <draft>draft-ietf-mmusic-msrp-usage-data-channel-24</draft>
        <updates>
            <doc-id>RFC4975</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC8873</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8874</doc-id>
        <title>Working Group GitHub Usage Guidance</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>B. Stark</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>git</kw>
            <kw>version control</kw>
            <kw>working group</kw>
            <kw>document</kw>
            <kw>editing</kw>
        </keywords>
        <abstract><p>This document provides a set of guidelines for working groups that choose to use GitHub for their work.</p></abstract>
        <draft>draft-ietf-git-using-github-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>git</wg_acronym>
        <doi>10.17487/RFC8874</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8875</doc-id>
        <title>Working Group GitHub Administration</title>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The use of GitHub in IETF working group processes is increasing.  This document describes uses and conventions for working groups that are considering starting to use GitHub.  It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub.</p></abstract>
        <draft>draft-ietf-git-github-wg-configuration-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>git</wg_acronym>
        <doi>10.17487/RFC8875</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8876</doc-id>
        <title>Non-interactive Emergency Calls</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>CAP</kw>
            <kw>Common Alerting Protocol</kw>
            <kw>Non-Interactive Emergency calls</kw>
        </keywords>
        <abstract><p>Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'.  In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text.  This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP).  That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does.  Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document.</p></abstract>
        <draft>draft-ietf-ecrit-data-only-ea-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC8876</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8877</doc-id>
        <title>Guidelines for Defining Packet Timestamps</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>J. Fabini</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Timestamps</kw>
        </keywords>
        <abstract><p>Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short.  This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers.  It also presents three recommended timestamp formats.  The target audience of this document includes network protocol designers.  It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats.  If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.</p></abstract>
        <draft>draft-ietf-ntp-packet-timestamps-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8877</errata-url>
        <doi>10.17487/RFC8877</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8878</doc-id>
        <title>Zstandard Compression and the 'application/zstd' Media Type</title>
        <author>
            <name>Y. Collet</name>
        </author>
        <author>
            <name>M. Kucherawy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>compression</kw>
        </keywords>
        <abstract><p>Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.</p><p> Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.</p><p> This document replaces and obsoletes RFC 8478.</p></abstract>
        <draft>draft-kucherawy-rfc8478bis-06</draft>
        <obsoletes>
            <doc-id>RFC8478</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9659</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8878</errata-url>
        <doi>10.17487/RFC8878</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8879</doc-id>
        <title>TLS Certificate Compression</title>
        <author>
            <name>A. Ghedini</name>
        </author>
        <author>
            <name>V. Vasiliev</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>zlib</kw>
            <kw>brotli</kw>
            <kw>zstd</kw>
        </keywords>
        <abstract><p>In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.</p><p> This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.</p></abstract>
        <draft>draft-ietf-tls-certificate-compression-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC8879</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8880</doc-id>
        <title>Special Use Domain Name 'ipv4only.arpa'</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>NAT64</kw>
            <kw>DNS64</kw>
        </keywords>
        <abstract><p>NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.</p><p> The specification for how a client discovers its local network's NAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.</p><p> Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties.</p><p> This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name. It also adds similar declarations for the corresponding reverse mapping names.</p></abstract>
        <draft>draft-cheshire-sudn-ipv4only-dot-arpa-17</draft>
        <updates>
            <doc-id>RFC7050</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8880</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8881</doc-id>
        <title>Network File System (NFS) Version 4 Minor Version 1 Protocol</title>
        <author>
            <name>D. Noveck</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Lever</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>560</page-count>
        <abstract><p>This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol.</p><p> This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661.</p></abstract>
        <draft>draft-ietf-nfsv4-rfc5661sesqui-msns-04</draft>
        <obsoletes>
            <doc-id>RFC5661</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8881</errata-url>
        <doi>10.17487/RFC8881</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8882</doc-id>
        <title>DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>D. Kaiser</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Multicast DNS</kw>
            <kw>mDNS</kw>
        </keywords>
        <abstract><p>DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services.  This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance.  Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise.  We analyze the requirements of a privacy-respecting discovery service.</p></abstract>
        <draft>draft-ietf-dnssd-prireq-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC8882</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8883</doc-id>
        <title>ICMPv6 Errors for Discarding Packets Due to Processing Limits</title>
        <author>
            <name>T. Herbert</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>extension Headers</kw>
            <kw>destination Options</kw>
            <kw>Hop-by-Hop Options</kw>
        </keywords>
        <abstract><p>Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits.  When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets.  This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers.  A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards.</p></abstract>
        <draft>draft-ietf-6man-icmp-limits-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8883</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8884</doc-id>
        <title>Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios</title>
        <author>
            <name>J. Seedorf</name>
        </author>
        <author>
            <name>M. Arumaithurai</name>
        </author>
        <author>
            <name>A. Tagami</name>
        </author>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <author>
            <name>N. Blefari-Melazzi</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ICN</kw>
        </keywords>
        <abstract><p>Information-Centric Networking (ICN) is a new paradigm where the network provides users with named content instead of communication channels between hosts.  This document outlines some research directions for ICN with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-disaster-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8884</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8885</doc-id>
        <title>Proxy Mobile IPv6 Extensions for Distributed Mobility Management</title>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>A. de la Oliva</name>
        </author>
        <author>
            <name>F. Giust</name>
        </author>
        <author>
            <name>JC. Zúñiga</name>
        </author>
        <author>
            <name>A. Mourad</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>PMIPv6</kw>
            <kw>anchor</kw>
            <kw>session continuity</kw>
            <kw>address reachability</kw>
            <kw>HNP</kw>
            <kw>CMD</kw>
            <kw>MAAR</kw>
        </keywords>
        <abstract><p>Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.</p><p> There are many different approaches to address Distributed Mobility Management -- for example, extending network-based mobility protocols (like Proxy Mobile IPv6) or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways.</p></abstract>
        <draft>draft-ietf-dmm-pmipv6-dlif-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC8885</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8886</doc-id>
        <title>Secure Device Install</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>C. Doyle</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>autoboot</kw>
            <kw>auto-boot</kw>
            <kw>autoinstall</kw>
            <kw>tftp</kw>
            <kw>install</kw>
            <kw>bunny</kw>
        </keywords>
        <abstract><p>Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support. In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.</p><p> This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device.</p></abstract>
        <draft>draft-ietf-opsawg-sdi-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8886</errata-url>
        <doi>10.17487/RFC8886</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8887</doc-id>
        <title>A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer.  The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP.</p></abstract>
        <draft>draft-ietf-jmap-websocket-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC8887</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8888</doc-id>
        <title>RTP Control Protocol (RTCP) Feedback for Congestion Control</title>
        <author>
            <name>Z. Sarker</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>V. Singh</name>
        </author>
        <author>
            <name>M. Ramalho</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Congestion control</kw>
            <kw>feedback message</kw>
            <kw>RTP</kw>
            <kw>RTCP</kw>
        </keywords>
        <abstract><p>An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets.  This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP.  The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control.</p></abstract>
        <draft>draft-ietf-avtcore-cc-feedback-message-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8888</errata-url>
        <doi>10.17487/RFC8888</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8889</doc-id>
        <title>Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring</title>
        <author>
            <name>G. Fioccola</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Cociglio</name>
        </author>
        <author>
            <name>A. Sapio</name>
        </author>
        <author>
            <name>R. Sisto</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Clustered Alternate Marking</kw>
            <kw>Multipoint Marking Method</kw>
            <kw>Multipoint Coloring Technique</kw>
            <kw>Network Clustering</kw>
        </keywords>
        <abstract><p>The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node.  This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network.  For this reason, the technique here described is called "Multipoint Alternate Marking".</p></abstract>
        <draft>draft-ietf-ippm-multipoint-alt-mark-09</draft>
        <obsoleted-by>
            <doc-id>RFC9342</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8889</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8890</doc-id>
        <title>The Internet is for End Users</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>stakeholder</kw>
        </keywords>
        <abstract><p>This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users.  It also explores how the IETF can more effectively achieve this.</p></abstract>
        <draft>draft-iab-for-the-users-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8890</errata-url>
        <doi>10.17487/RFC8890</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8891</doc-id>
        <title>GOST R 34.12-2015: Block Cipher "Magma"</title>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Baryshkov</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Magma</kw>
            <kw>Block Cipher</kw>
        </keywords>
        <abstract><p>In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma".  The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830).  This document is intended to be a source of information about the updated version of the 64-bit cipher.  It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption.</p></abstract>
        <draft>draft-dolmatov-magma-06</draft>
        <updates>
            <doc-id>RFC5830</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8891</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8892</doc-id>
        <title>Guidelines and Registration Procedures for Interface Types and Tunnel Types</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>August</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>ifType</kw>
            <kw>tunnelType</kw>
            <kw>Transmission Number</kw>
        </keywords>
        <abstract><p>This document provides guidelines and procedures for those who are
defining, registering, or evaluating definitions of new interface
types ("ifType" values) and tunnel types.  The original definition of
the IANA interface type registry predated the use of IANA
Considerations sections and YANG modules, so some confusion arose
over time.  Tunnel types were added later, with the same requirements
and allocation policy as interface types.  This document updates RFC
2863 and provides updated guidance for these registries.</p></abstract>
        <draft>draft-thaler-iftype-reg-07</draft>
        <updates>
            <doc-id>RFC2863</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8892</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8893</doc-id>
        <title>Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Volk</name>
        </author>
        <author>
            <name>J. Heitz</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>security</kw>
            <kw>RPKI</kw>
        </keywords>
        <abstract><p>A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors.  For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS.  This document updates RFC 6811.</p></abstract>
        <draft>draft-ietf-sidrops-ov-egress-04</draft>
        <updates>
            <doc-id>RFC6811</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8893</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8894</doc-id>
        <title>Simple Certificate Enrolment Protocol</title>
        <author>
            <name>P. Gutmann</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP.  SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.</p></abstract>
        <draft>draft-gutmann-scep-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8894</errata-url>
        <doi>10.17487/RFC8894</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8895</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)</title>
        <author>
            <name>W. Roome</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>ALTO</kw>
        </keywords>
        <abstract><p>The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources.  This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.</p></abstract>
        <draft>draft-ietf-alto-incr-update-sse-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8895</errata-url>
        <doi>10.17487/RFC8895</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8896</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Cost Calendar</title>
        <author>
            <name>S. Randriamasy</name>
        </author>
        <author>
            <name>R. Yang</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>L. Deng</name>
        </author>
        <author>
            <name>N. Schwan</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol.  It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'.  This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example.  This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval.  The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.</p></abstract>
        <draft>draft-ietf-alto-cost-calendar-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC8896</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8897</doc-id>
        <title>Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties</title>
        <author>
            <name>D. Ma</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI).  It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements.  Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein.</p></abstract>
        <draft>draft-ietf-sidrops-rp-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC8897</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8898</doc-id>
        <title>Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)</title>
        <author>
            <name>R. Shekh-Yusef</name>
        </author>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>V. Pascual</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SIP OAuth</kw>
            <kw>3rd party authentication</kw>
            <kw>Third party authentication</kw>
        </keywords>
        <abstract><p>This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP) and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0.  This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields.</p></abstract>
        <draft>draft-ietf-sipcore-sip-token-authnz-17</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8898</errata-url>
        <doi>10.17487/RFC8898</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8899</doc-id>
        <title>Packetization Layer Path MTU Discovery for Datagram Transports</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>T. Jones</name>
        </author>
        <author>
            <name>M. Tüxen</name>
        </author>
        <author>
            <name>I. Rüngeler</name>
        </author>
        <author>
            <name>T. Völker</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>UDP</kw>
            <kw>SCTP</kw>
            <kw>Transport</kw>
            <kw>PMTUD</kw>
            <kw>PLPMTUD</kw>
        </keywords>
        <abstract><p>This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.</p><p> The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports.</p><p> This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261.</p></abstract>
        <draft>draft-ietf-tsvwg-datagram-plpmtud-22</draft>
        <updates>
            <doc-id>RFC4821</doc-id>
            <doc-id>RFC4960</doc-id>
            <doc-id>RFC6951</doc-id>
            <doc-id>RFC8085</doc-id>
            <doc-id>RFC8261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC8899</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8900</doc-id>
        <title>IP Fragmentation Considered Fragile</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>F. Gont</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Fragmentation</kw>
        </keywords>
        <abstract><p>This document describes IP fragmentation and explains how it introduces fragility to Internet communication.</p><p> This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.</p></abstract>
        <draft>draft-ietf-intarea-frag-fragile-17</draft>
        <is-also>
            <doc-id>BCP0230</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <doi>10.17487/RFC8900</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8901</doc-id>
        <title>Multi-Signer DNSSEC Models</title>
        <author>
            <name>S. Huque</name>
        </author>
        <author>
            <name>P. Aras</name>
        </author>
        <author>
            <name>J. Dickinson</name>
        </author>
        <author>
            <name>J. Vcelak</name>
        </author>
        <author>
            <name>D. Blacka</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>Multiple</kw>
            <kw>Provider</kw>
            <kw>Signer</kw>
            <kw>Models</kw>
        </keywords>
        <abstract><p>Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service.  Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use.  In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary.  This document presents deployment models that accommodate this scenario and describes these key-management requirements.  These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.</p></abstract>
        <draft>draft-ietf-dnsop-multi-provider-dnssec-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8901</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8902</doc-id>
        <title>TLS Authentication Using Intelligent Transport System (ITS) Certificates</title>
        <author>
            <name>M. Msahli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Cam-Winget</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Whyte</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Serhrouchni</name>
        </author>
        <author>
            <name>H. Labiod</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>Intelligent Transport System (ITS) Certificates</kw>
            <kw>IEEE</kw>
            <kw>ETSI</kw>
        </keywords>
        <abstract><p>The IEEE and ETSI have specified a type of end-entity certificate.  This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities.</p></abstract>
        <draft>draft-msahli-ise-ieee1609-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8902</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8903</doc-id>
        <title>Use Cases for DDoS Open Threat Signaling</title>
        <author>
            <name>R. Dobbins</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>N. Teague</name>
        </author>
        <author>
            <name>L. Xia</name>
        </author>
        <author>
            <name>K. Nishizuka</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS Mitigation solutions.  This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges.  These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.</p></abstract>
        <draft>draft-ietf-dots-use-cases-25</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC8903</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8904</doc-id>
        <title>DNS Whitelist (DNSWL) Email Authentication Method Extension</title>
        <author>
            <name>A. Vesely</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNSWL</kw>
            <kw>EMAIL</kw>
            <kw>Authentication-Results</kw>
        </keywords>
        <abstract><p>This document describes an email authentication method compliant with RFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.</p><p> This document does not consider blacklists.</p></abstract>
        <draft>draft-vesely-authmethod-dnswl-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8904</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8905</doc-id>
        <title>The 'payto' URI Scheme for Payments</title>
        <author>
            <name>F. Dold</name>
        </author>
        <author>
            <name>C. Grothoff</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>payments</kw>
        </keywords>
        <abstract><p>This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.</p><p> A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.</p></abstract>
        <draft>draft-dold-payto-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8905</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8906</doc-id>
        <title>A Common Operational Problem in DNS Servers: Failure to Communicate</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <author>
            <name>R. Bellis</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>conformance</kw>
            <kw>compliance</kw>
        </keywords>
        <abstract><p>The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.</p><p> This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.</p><p> The document does not look at the DNS data itself, just the structure of the responses.</p></abstract>
        <draft>draft-ietf-dnsop-no-response-issue-23</draft>
        <is-also>
            <doc-id>BCP0231</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8906</errata-url>
        <doi>10.17487/RFC8906</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8907</doc-id>
        <title>The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol</title>
        <author>
            <name>T. Dahm</name>
        </author>
        <author>
            <name>A. Ota</name>
        </author>
        <author>
            <name>D.C. Medway Gash</name>
        </author>
        <author>
            <name>D. Carrel</name>
        </author>
        <author>
            <name>L. Grant</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>TACACS+</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract><p>This document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.</p></abstract>
        <draft>draft-ietf-opsawg-tacacs-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8907</errata-url>
        <doi>10.17487/RFC8907</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8908</doc-id>
        <title>Captive Portal API</title>
        <author>
            <name>T. Pauly</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Thakore</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes an HTTP API that allows clients to interact with a Captive Portal system.  With this API, clients can discover how to get out of captivity and fetch state about their Captive Portal sessions.</p></abstract>
        <draft>draft-ietf-capport-api-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>capport</wg_acronym>
        <doi>10.17487/RFC8908</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8909</doc-id>
        <title>Registry Data Escrow Specification</title>
        <author>
            <name>G. Lozano</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>data escrow</kw>
            <kw>registry</kw>
        </keywords>
        <abstract><p>This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries.  The specification is designed to be independent of the underlying objects that are being escrowed, and therefore it could also be used for purposes other than domain name registries.</p></abstract>
        <draft>draft-ietf-regext-data-escrow-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8909</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8910</doc-id>
        <title>Captive-Portal Identification in DHCP and Router Advertisements (RAs)</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>E. Kline</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Captive Portal</kw>
            <kw>Walled Garden</kw>
            <kw>Coffee-shop</kw>
            <kw>Hotel</kw>
        </keywords>
        <abstract><p>In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.</p><p> This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.</p><p> This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.</p></abstract>
        <draft>draft-ietf-capport-rfc7710bis-10</draft>
        <obsoletes>
            <doc-id>RFC7710</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3679</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>capport</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8910</errata-url>
        <doi>10.17487/RFC8910</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8911</doc-id>
        <title>Registry for Performance Metrics</title>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>A. Akhter</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>Loss</kw>
            <kw>Delay</kw>
        </keywords>
        <abstract><p>This document defines the format for the IANA Registry of Performance
Metrics.  This document also gives a set of guidelines for Registered
Performance Metric requesters and reviewers.</p></abstract>
        <draft>draft-ietf-ippm-metric-registry-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC8911</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8912</doc-id>
        <title>Initial Performance Metrics Registry Entries</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>P. Eardley</name>
        </author>
        <author>
            <name>K. D'Souza</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>71</page-count>
        <abstract><p>This memo defines the set of initial entries for the IANA Registry of
Performance Metrics.  The set includes UDP Round-Trip Latency and
Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP
Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,
ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.</p></abstract>
        <draft>draft-ietf-ippm-initial-registry-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8912</errata-url>
        <doi>10.17487/RFC8912</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8913</doc-id>
        <title>Two-Way Active Measurement Protocol (TWAMP) YANG Data Model</title>
        <author>
            <name>R. Civil</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>K. Pentikousis</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>60</page-count>
        <abstract><p>This document specifies a data model for client and server
implementations of the Two-Way Active Measurement Protocol (TWAMP).
This document defines the TWAMP data model through Unified Modeling
Language (UML) class diagrams and formally specifies it using the
YANG data modeling language (RFC 7950).  The data model is compliant
with the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-ippm-twamp-yang-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8913</errata-url>
        <doi>10.17487/RFC8913</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8914</doc-id>
        <title>Extended DNS Errors</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>E. Hunt</name>
        </author>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>D. Lawrence</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document defines an extensible method to return additional information about the cause of DNS errors.  Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information.  Extended DNS Error information does not change the processing of RCODEs.</p></abstract>
        <draft>draft-ietf-dnsop-extended-error-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC8914</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8915</doc-id>
        <title>Network Time Security for the Network Time Protocol</title>
        <author>
            <name>D. Franke</name>
        </author>
        <author>
            <name>D. Sibold</name>
        </author>
        <author>
            <name>K. Teichel</name>
        </author>
        <author>
            <name>M. Dansarie</name>
        </author>
        <author>
            <name>R. Sundblad</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Integrity</kw>
            <kw>Authentication</kw>
            <kw>NTP</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).</p><p> NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.</p></abstract>
        <draft>draft-ietf-ntp-using-nts-for-ntp-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC8915</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8916</doc-id>
        <title>A YANG Data Model for the Multicast Source Discovery Protocol (MSDP)</title>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>Z. Zhang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Peter</name>
        </author>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <author>
            <name>F. Guo</name>
        </author>
        <author>
            <name>P. McAllister</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>MSDP</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for the configuration and management of Multicast Source Discovery Protocol (MSDP) protocol operations.</p></abstract>
        <draft>draft-ietf-pim-msdp-yang-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC8916</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8917</doc-id>
        <title>The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>location</kw>
            <kw>LoST</kw>
            <kw>emergency</kw>
            <kw>emergency services</kw>
            <kw>ecrf</kw>
            <kw>lvf</kw>
            <kw>i3</kw>
        </keywords>
        <abstract><p>This document adds the 'LoST-Validation' service tag to the Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry.  This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifying LoST servers designated for location validation.  This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.</p></abstract>
        <draft>draft-gellens-lost-validation-09</draft>
        <updates>
            <doc-id>RFC5222</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8917</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8918</doc-id>
        <title>Invalid TLV Handling in IS-IS</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>P. Wells</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <date>
            <month>September</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TLV</kw>
            <kw>IS-IS</kw>
        </keywords>
        <abstract><p>The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received.</p><p> This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.</p><p> This document updates RFCs 5305 and 6232.</p></abstract>
        <draft>draft-ietf-lsr-isis-invalid-tlv-03</draft>
        <updates>
            <doc-id>RFC5305</doc-id>
            <doc-id>RFC6232</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC8918</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8919</doc-id>
        <title>IS-IS Application-Specific Link Attributes</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements that address both of these shortcomings.</p></abstract>
        <draft>draft-ietf-isis-te-app-19</draft>
        <obsoleted-by>
            <doc-id>RFC9479</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8919</errata-url>
        <doi>10.17487/RFC8919</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8920</doc-id>
        <title>OSPF Application-Specific Link Attributes</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.</p></abstract>
        <draft>draft-ietf-ospf-te-link-attr-reuse-16</draft>
        <obsoleted-by>
            <doc-id>RFC9492</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8920</errata-url>
        <doi>10.17487/RFC8920</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8921</doc-id>
        <title>Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <author>
            <name>D. Zhang</name>
        </author>
        <author>
            <name>P. Georgatsos</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>SDN</kw>
            <kw>Order Request Handling</kw>
            <kw>Automation</kw>
            <kw>Dynamic Provisioning</kw>
            <kw>CDN</kw>
            <kw>Interconnection</kw>
            <kw>Service Delivery</kw>
            <kw>Service Activation</kw>
        </keywords>
        <abstract><p>This document defines the Connectivity Provisioning Negotiation Protocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.</p><p> CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc.</p></abstract>
        <draft>draft-boucadair-connectivity-provisioning-protocol-22</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8921</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8922</doc-id>
        <title>A Survey of the Interaction between Security Protocols and Transport Services</title>
        <author>
            <name>T. Enghardt</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>K. Rose</name>
        </author>
        <author>
            <name>C. Wood</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Transport Protocols</kw>
            <kw>Transport Security</kw>
        </keywords>
        <abstract><p>This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols.  Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols.  This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support.</p></abstract>
        <draft>draft-ietf-taps-transport-security-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <doi>10.17487/RFC8922</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8923</doc-id>
        <title>A Minimal Set of Transport Services for End Systems</title>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>S. Gjessing</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>taps</kw>
            <kw>transport services</kw>
        </keywords>
        <abstract><p>This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols.  It is based on the set of transport features in RFC 8303.</p></abstract>
        <draft>draft-ietf-taps-minset-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <doi>10.17487/RFC8923</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8924</doc-id>
        <title>Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework</title>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>C. Pignataro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>N. Kumar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Krishnan</name>
        </author>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>SFC</kw>
            <kw>OAM</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract><p>This document provides a reference framework for Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC).</p></abstract>
        <draft>draft-ietf-sfc-oam-framework-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC8924</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8925</doc-id>
        <title>IPv6-Only Preferred Option for DHCPv4</title>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity.  It also updates RFC 2563 to specify DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document.</p></abstract>
        <draft>draft-ietf-dhc-v6only-08</draft>
        <updates>
            <doc-id>RFC2563</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8925</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8926</doc-id>
        <title>Geneve: Generic Network Virtualization Encapsulation</title>
        <author>
            <name>J. Gross</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Ganga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Sridhar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>overlay</kw>
            <kw>tunnel</kw>
            <kw>extensible</kw>
            <kw>variable</kw>
            <kw>metadata</kw>
            <kw>options</kw>
            <kw>endpoint</kw>
            <kw>transit</kw>
        </keywords>
        <abstract><p>Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters.  As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components.  Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology.  This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</p></abstract>
        <draft>draft-ietf-nvo3-geneve-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC8926</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8927</doc-id>
        <title>JSON Type Definition</title>
        <author>
            <name>U. Carion</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>data interchange format</kw>
            <kw>description language</kw>
            <kw>schema language</kw>
            <kw>tree grammar</kw>
        </keywords>
        <abstract><p>This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators. To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.</p><p> This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD.</p></abstract>
        <draft>draft-ucarion-json-type-definition-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8927</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8928</doc-id>
        <title>Address-Protected Neighbor Discovery for Low-Power and Lossy Networks</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>M. Sethi</name>
        </author>
        <author>
            <name>R. Struik</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Address registration</kw>
            <kw>Network Overlay</kw>
            <kw>host to router interface</kw>
        </keywords>
        <abstract><p>This document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505.  The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN).  Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses.  The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses.  Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.</p></abstract>
        <draft>draft-ietf-6lo-ap-nd-23</draft>
        <updates>
            <doc-id>RFC8505</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8928</errata-url>
        <doi>10.17487/RFC8928</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8929</doc-id>
        <title>IPv6 Backbone Router</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C.E. Perkins</name>
        </author>
        <author>
            <name>E. Levy-Abegnoli</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>ND Proxy</kw>
            <kw>Routing Proxy</kw>
            <kw>Bridging Proxy</kw>
            <kw>proxy ND</kw>
            <kw>proxy-ND</kw>
        </keywords>
        <abstract><p>This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers".  Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN).</p></abstract>
        <draft>draft-ietf-6lo-backbone-router-20</draft>
        <updates>
            <doc-id>RFC6775</doc-id>
            <doc-id>RFC8505</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8929</errata-url>
        <doi>10.17487/RFC8929</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8930</doc-id>
        <title>On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network</title>
        <author>
            <name>T. Watteyne</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>6LoWPAN</kw>
            <kw>Fragment</kw>
        </keywords>
        <abstract><p>This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network.  Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs).</p></abstract>
        <draft>draft-ietf-6lo-minimal-fragment-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC8930</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8931</doc-id>
        <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>LLN</kw>
            <kw>Route-Over</kw>
            <kw>mesh</kw>
            <kw>IoT</kw>
        </keywords>
        <abstract><p>This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network.</p></abstract>
        <draft>draft-ietf-6lo-fragment-recovery-21</draft>
        <updates>
            <doc-id>RFC4944</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC8931</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8932</doc-id>
        <title>Recommendations for DNS Privacy Service Operators</title>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>B. Overeinder</name>
        </author>
        <author>
            <name>R. van Rijswijk-Deij</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.</p><p> This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841.</p></abstract>
        <draft>draft-ietf-dprive-bcp-op-14</draft>
        <is-also>
            <doc-id>BCP0232</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8932</errata-url>
        <doi>10.17487/RFC8932</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8933</doc-id>
        <title>Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>algorithm identifier integrity</kw>
        </keywords>
        <abstract><p>This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.</p></abstract>
        <draft>draft-ietf-lamps-cms-update-alg-id-protect-05</draft>
        <updates>
            <doc-id>RFC5652</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8933</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8934</doc-id>
        <title>PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE</title>
        <author>
            <name>H. Chen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Zhuang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Path Computation Element</kw>
        </keywords>
        <abstract><p>This document defines a set of extensions to the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-lsp-scheduling-27</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC8934</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8935</doc-id>
        <title>Push-Based Security Event Token (SET) Delivery Using HTTP</title>
        <author>
            <name>A. Backman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jones</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Scurtescu</name>
        </author>
        <author>
            <name>M. Ansari</name>
        </author>
        <author>
            <name>A. Nadalin</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>Security Event Token</kw>
            <kw>SET</kw>
            <kw>Delivery</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS.  The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response.</p></abstract>
        <draft>draft-ietf-secevent-http-push-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secevent</wg_acronym>
        <doi>10.17487/RFC8935</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8936</doc-id>
        <title>Poll-Based Security Event Token (SET) Delivery Using HTTP</title>
        <author>
            <name>A. Backman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jones</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Scurtescu</name>
        </author>
        <author>
            <name>M. Ansari</name>
        </author>
        <author>
            <name>A. Nadalin</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>Security Event Token</kw>
            <kw>SET</kw>
            <kw>Delivery</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient.  The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance.</p></abstract>
        <draft>draft-ietf-secevent-http-poll-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secevent</wg_acronym>
        <doi>10.17487/RFC8936</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8937</doc-id>
        <title>Randomness Improvements for Security Protocols</title>
        <author>
            <name>C. Cremers</name>
        </author>
        <author>
            <name>L. Garratt</name>
        </author>
        <author>
            <name>S. Smyshlyaev</name>
        </author>
        <author>
            <name>N. Sullivan</name>
        </author>
        <author>
            <name>C. Wood</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Cryptography</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-randomness-improvements-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8937</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8938</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane Framework</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document provides an overall framework for the Deterministic Networking (DetNet) data plane.  It covers concepts and considerations that are generally common to any DetNet data plane specification.  It describes related Controller Plane considerations as well.</p></abstract>
        <draft>draft-ietf-detnet-data-plane-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC8938</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8939</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: IP</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Application</kw>
            <kw>Endpoint</kw>
            <kw>Service Sub-layer</kw>
            <kw>Forwarding Sub-layer</kw>
        </keywords>
        <abstract><p>This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery.  This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).</p></abstract>
        <draft>draft-ietf-detnet-ip-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC8939</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8940</doc-id>
        <title>Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP)</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>October</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>PEAP</kw>
            <kw>EAP-AKA</kw>
            <kw>EAP-SIM</kw>
            <kw>ERP</kw>
            <kw>FILS</kw>
            <kw>Session-ID</kw>
            <kw>fast reconnect</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods.  The derivation of Session-Id was not given for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication.  The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA.  The derivation of Session-Id for Protected EAP (PEAP) is also given.  The definition for PEAP follows the definition for other TLS-based EAP methods.</p></abstract>
        <draft>draft-ietf-emu-eap-session-id-07</draft>
        <updates>
            <doc-id>RFC5247</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC8940</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8941</doc-id>
        <title>Structured Field Values for HTTP</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>P-H. Kamp</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>trailer</kw>
            <kw>header</kw>
        </keywords>
        <abstract><p>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</p></abstract>
        <draft>draft-ietf-httpbis-header-structure-19</draft>
        <obsoleted-by>
            <doc-id>RFC9651</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8941</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8942</doc-id>
        <title>HTTP Client Hints</title>
        <author>
            <name>I. Grigorik</name>
        </author>
        <author>
            <name>Y. Weiss</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Content Negotiation</kw>
        </keywords>
        <abstract><p>HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.</p><p> This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints."</p></abstract>
        <draft>draft-ietf-httpbis-client-hints-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC8942</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8943</doc-id>
        <title>Concise Binary Object Representation (CBOR) Tags for Date</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>A. Nadalin</name>
        </author>
        <author>
            <name>J. Richter</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Compact Binary Object Representation</kw>
            <kw>CBOR</kw>
            <kw>Tag</kw>
            <kw>Date</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.</p><p> In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined.</p></abstract>
        <draft>draft-ietf-cbor-date-tag-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC8943</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8944</doc-id>
        <title>A YANG Data Model for Layer 2 Network Topologies</title>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>X. Wei</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>A. Liu</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>This document defines a YANG data model for Layer 2 network topologies.  In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2.</p></abstract>
        <draft>draft-ietf-i2rs-yang-l2-network-topology-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>i2rs</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8944</errata-url>
        <doi>10.17487/RFC8944</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8945</doc-id>
        <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
        <author>
            <name>F. Dupont</name>
        </author>
        <author>
            <name>S. Morris</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>B. Wellington</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.</p><p> No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.</p><p> This document obsoletes RFCs 2845 and 4635.</p></abstract>
        <draft>draft-ietf-dnsop-rfc2845bis-09</draft>
        <obsoletes>
            <doc-id>RFC2845</doc-id>
            <doc-id>RFC4635</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0093</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8945</errata-url>
        <doi>10.17487/RFC8945</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8946</doc-id>
        <title>Personal Assertion Token (PASSporT) Extension for Diverted Calls</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>STIR</kw>
            <kw>Identity</kw>
        </keywords>
        <abstract><p>The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios.</p><p> This document updates RFC 8224.</p></abstract>
        <draft>draft-ietf-stir-passport-divert-09</draft>
        <updates>
            <doc-id>RFC8224</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC8946</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8947</doc-id>
        <title>Link-Layer Address Assignment Mechanism for DHCPv6</title>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner.  Such devices may have their link-layer addresses assigned in an automated fashion.  With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable.  Therefore, an allocation mechanism is required.  This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.</p></abstract>
        <draft>draft-ietf-dhc-mac-assign-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8947</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8948</doc-id>
        <title>Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6</title>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>A. Mourad</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>IEEE 802c</kw>
            <kw>ELI</kw>
            <kw>SAI</kw>
            <kw>AAI</kw>
            <kw>MAC address</kw>
            <kw>LLADDR</kw>
        </keywords>
        <abstract><p>The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.</p><p> The IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.</p><p> This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option (QUAD) is defined for this purpose.</p></abstract>
        <draft>draft-ietf-dhc-slap-quadrant-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8948</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8949</doc-id>
        <title>Concise Binary Object Representation (CBOR)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>parser</kw>
            <kw>decoder</kw>
            <kw>encoder</kw>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</p><p> This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</p></abstract>
        <draft>draft-ietf-cbor-7049bis-16</draft>
        <obsoletes>
            <doc-id>RFC7049</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0094</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8949</errata-url>
        <doi>10.17487/RFC8949</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8950</doc-id>
        <title>Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>S. Agrawal</name>
        </author>
        <author>
            <name>K. Ananthamurthy</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>bgp</kw>
            <kw>mvpn</kw>
            <kw>vpnv4</kw>
            <kw>vpnv6</kw>
        </keywords>
        <abstract><p>Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.</p><p> This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549.</p></abstract>
        <draft>draft-ietf-bess-rfc5549revision-06</draft>
        <obsoletes>
            <doc-id>RFC5549</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC8950</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8951</doc-id>
        <title>Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>T. Werner</name>
        </author>
        <author>
            <name>W. Pan</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>CSRattributes</kw>
            <kw>BRSKI</kw>
            <kw>RFC7030</kw>
        </keywords>
        <abstract><p>This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.</p><p> This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present.</p></abstract>
        <draft>draft-ietf-lamps-rfc7030est-clarify-10</draft>
        <updates>
            <doc-id>RFC7030</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8951</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8952</doc-id>
        <title>Captive Portal Architecture</title>
        <author>
            <name>K. Larose</name>
        </author>
        <author>
            <name>D. Dolson</name>
        </author>
        <author>
            <name>H. Liu</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Captive Portal</kw>
            <kw>Architecture</kw>
            <kw>Wifi</kw>
            <kw>Wi-Fi</kw>
            <kw>Wireless</kw>
            <kw>Roaming</kw>
            <kw>Mobile</kw>
            <kw>API</kw>
        </keywords>
        <abstract><p>This document describes a captive portal architecture.  Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.</p></abstract>
        <draft>draft-ietf-capport-architecture-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>capport</wg_acronym>
        <doi>10.17487/RFC8952</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8953</doc-id>
        <title>Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report</title>
        <author>
            <name>K. Moriarty</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>Attack Response</kw>
            <kw>CARIS</kw>
            <kw>Incident</kw>
        </keywords>
        <abstract><p>The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place on 28 February and 1 March 2019 in Cambridge, Massachusetts, USA.  Participants spanned regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities.  This workshop continued the work started at the first CARIS workshop, with a focus on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption.</p></abstract>
        <draft>draft-moriarty-caris2-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8953</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8954</doc-id>
        <title>Online Certificate Status Protocol (OCSP) Nonce Extension</title>
        <author>
            <name>M. Sahni</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>OCSP Nonce Length</kw>
            <kw>OCSP Nonce Randomness</kw>
        </keywords>
        <abstract><p>This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages.  OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message.  This document updates RFC 6960.</p></abstract>
        <draft>draft-ietf-lamps-ocsp-nonce-05</draft>
        <obsoleted-by>
            <doc-id>RFC9654</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC6960</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC8954</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8955</doc-id>
        <title>Dissemination of Flow Specification Rules</title>
        <author>
            <name>C. Loibl</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>M. Bacher</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</p><p> It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.</p><p> This document obsoletes both RFC 5575 and RFC 7674.</p></abstract>
        <draft>draft-ietf-idr-rfc5575bis-27</draft>
        <obsoletes>
            <doc-id>RFC5575</doc-id>
            <doc-id>RFC7674</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC8956</doc-id>
            <doc-id>RFC9117</doc-id>
            <doc-id>RFC9184</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8955</errata-url>
        <doi>10.17487/RFC8955</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8956</doc-id>
        <title>Dissemination of Flow Specification Rules for IPv6</title>
        <author>
            <name>C. Loibl</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Raszuk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hares</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>BGP Flow Specification</kw>
            <kw>V6</kw>
        </keywords>
        <abstract><p>"Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.</p><p> This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.</p></abstract>
        <draft>draft-ietf-idr-flow-spec-v6-22</draft>
        <updates>
            <doc-id>RFC8955</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8956</errata-url>
        <doi>10.17487/RFC8956</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8957</doc-id>
        <title>Synonymous Flow Label Framework</title>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Flow</kw>
            <kw>Label</kw>
        </keywords>
        <abstract><p>RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture.  This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service.  These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.</p></abstract>
        <draft>draft-ietf-mpls-sfl-framework-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC8957</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8958</doc-id>
        <title>Updated Registration Rules for URI.ARPA</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the URI.ARPA zone.</p></abstract>
        <draft>draft-hardie-dispatch-rfc3405-update-04</draft>
        <updates>
            <doc-id>RFC3405</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0065</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8958</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8959</doc-id>
        <title>The "secret-token" URI Scheme</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>bearer token</kw>
            <kw>token scanning</kw>
        </keywords>
        <abstract><p>This document registers the "secret-token" URI scheme to aid in the identification of authentication tokens.</p></abstract>
        <draft>draft-nottingham-how-did-that-get-into-the-repo-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8959</errata-url>
        <doi>10.17487/RFC8959</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8960</doc-id>
        <title>A YANG Data Model for MPLS Base</title>
        <author>
            <name>T. Saad</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>R. Gandhi</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>V. Beeram</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>MPLS YANG Data Model</kw>
            <kw>MPLS Model</kw>
            <kw>MPLS RIB</kw>
            <kw>MPLS Routing Information Base</kw>
        </keywords>
        <abstract><p>This document contains a specification of the MPLS base YANG data model.  The MPLS base YANG data model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS-enabled router.  It is expected that other MPLS YANG data models (e.g., MPLS Label Switched Path (LSP) static, LDP, or RSVP-TE YANG data models) will augment the MPLS base YANG data model.</p></abstract>
        <draft>draft-ietf-mpls-base-yang-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8960</errata-url>
        <doi>10.17487/RFC8960</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8961</doc-id>
        <title>Requirements for Time-Based Loss Detection</title>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>November</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>retransmission timeout</kw>
            <kw> packet loss</kw>
            <kw> loss detection</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract><p>Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path).  While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet "lost".  Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations.  This document provides high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet.  Within the requirements, implementations have latitude to define particulars that best address each situation.</p></abstract>
        <draft>draft-ietf-tcpm-rto-consider-17</draft>
        <is-also>
            <doc-id>BCP0233</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC8961</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8962</doc-id>
        <title>Establishing the Protocol Police</title>
        <author>
            <name>G. Grover</name>
        </author>
        <author>
            <name>N. ten Oever</name>
        </author>
        <author>
            <name>C. Cath</name>
        </author>
        <author>
            <name>S. Sahib</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.</p><p> This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police.</p></abstract>
        <draft>draft-protocolpolice-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8962</errata-url>
        <doi>10.17487/RFC8962</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8963</doc-id>
        <title>Evaluation of a Sample of RFCs Produced in 2018</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. We analyze a set of randomly chosen RFCs approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH48 phase.</p><p> We also measure the number of citations of the chosen RFC using Semantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that.</p></abstract>
        <draft>draft-huitema-rfc-eval-project-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc8963</errata-url>
        <doi>10.17487/RFC8963</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8964</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: MPLS</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>detnet</kw>
            <kw>mpls</kw>
            <kw>preof</kw>
            <kw>pref</kw>
            <kw>peof</kw>
            <kw>prf</kw>
            <kw>pef</kw>
            <kw>pof</kw>
            <kw>protection</kw>
            <kw>replication</kw>
            <kw>elimination</kw>
        </keywords>
        <abstract><p>This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network.  It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms.  This document builds on the DetNet architecture and data plane framework.</p></abstract>
        <draft>draft-ietf-detnet-mpls-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC8964</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8965</doc-id>
        <title>Applicability of the Babel Routing Protocol</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>distance-vector</kw>
            <kw>loop</kw>
            <kw>starvation</kw>
            <kw>Bellman-Ford</kw>
            <kw>routing</kw>
            <kw>routing protocol</kw>
            <kw>wireless</kw>
            <kw>mesh network</kw>
            <kw>IGP</kw>
        </keywords>
        <abstract><p>Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance.  This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols.</p></abstract>
        <draft>draft-ietf-babel-applicability-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC8965</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8966</doc-id>
        <title>The Babel Routing Protocol</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>Bellman-Ford</kw>
            <kw>IGP</kw>
            <kw>loop-avoidance</kw>
            <kw>mesh network</kw>
        </keywords>
        <abstract><p>Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.  This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557.</p></abstract>
        <draft>draft-ietf-babel-rfc6126bis-20</draft>
        <obsoletes>
            <doc-id>RFC6126</doc-id>
            <doc-id>RFC7557</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8966</errata-url>
        <doi>10.17487/RFC8966</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8967</doc-id>
        <title>MAC Authentication for the Babel Routing Protocol</title>
        <author>
            <name>C. Dô</name>
        </author>
        <author>
            <name>W. Kolodziejak</name>
        </author>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>routing protocol</kw>
            <kw>authentication</kw>
            <kw>replay</kw>
            <kw>replay protection</kw>
        </keywords>
        <abstract><p>This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance.  This document obsoletes RFC 7298.</p></abstract>
        <draft>draft-ietf-babel-hmac-12</draft>
        <obsoletes>
            <doc-id>RFC7298</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9467</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC8967</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8968</doc-id>
        <title>Babel Routing Protocol over Datagram Transport Layer Security</title>
        <author>
            <name>A. Décimo</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them.  This document specifies a mechanism to ensure these properties using Datagram Transport Layer Security (DTLS).</p></abstract>
        <draft>draft-ietf-babel-dtls-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC8968</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8969</doc-id>
        <title>A Framework for Automating Service and Network Management with YANG</title>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>C. Xie</name>
        </author>
        <author>
            <name>L. Geng</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>Model Driven</kw>
            <kw>YANG Data Model</kw>
            <kw>automation</kw>
            <kw>service delivery</kw>
            <kw>notification</kw>
            <kw>SDN</kw>
        </keywords>
        <abstract><p>Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.</p><p> This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.</p></abstract>
        <draft>draft-ietf-opsawg-model-automation-framework-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8969</errata-url>
        <doi>10.17487/RFC8969</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8970</doc-id>
        <title>IMAP4 Extension: Message Preview Generation</title>
        <author>
            <name>M. Slusarz</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IMAP4</kw>
            <kw>FETCH</kw>
            <kw>PREVIEW</kw>
        </keywords>
        <abstract><p>This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message.</p></abstract>
        <draft>draft-ietf-extra-imap-fetch-preview-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC8970</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8971</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)</title>
        <author>
            <name>S. Pallagatti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Paragiri</name>
        </author>
        <author>
            <name>V. Govindan</name>
        </author>
        <author>
            <name>M. Mudigonda</name>
        </author>
        <date>
            <month>December</month>
            <year>2020</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>BFD for VXLAN</kw>
        </keywords>
        <abstract><p>This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels used to form an overlay network.</p></abstract>
        <draft>draft-ietf-bfd-vxlan-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8971</errata-url>
        <doi>10.17487/RFC8971</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8972</doc-id>
        <title>Simple Two-Way Active Measurement Protocol Optional Extensions</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>X. Min</name>
        </author>
        <author>
            <name>H. Nydell</name>
        </author>
        <author>
            <name>R. Foote</name>
        </author>
        <author>
            <name>A. Masputra</name>
        </author>
        <author>
            <name>E. Ruffini</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>Performance Measurement</kw>
        </keywords>
        <abstract><p>This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics.  The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.</p></abstract>
        <draft>draft-ietf-ippm-stamp-option-tlv-10</draft>
        <updates>
            <doc-id>RFC8762</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8972</errata-url>
        <doi>10.17487/RFC8972</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8973</doc-id>
        <title>DDoS Open Threat Signaling (DOTS) Agent Discovery</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Automation</kw>
            <kw>Provisioning</kw>
            <kw>Configuration</kw>
            <kw>Location</kw>
            <kw>Deployment</kw>
            <kw>Multihoming</kw>
            <kw>DDoS</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document specifies mechanisms to configure DDoS Open Threat Signaling (DOTS) clients with their DOTS servers.  The discovery procedure also covers the DOTS signal channel Call Home.  It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions.  This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed.</p></abstract>
        <draft>draft-ietf-dots-server-discovery-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC8973</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8974</doc-id>
        <title>Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)</title>
        <author>
            <name>K. Hartke</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>6tisch</kw>
            <kw>minimal-security</kw>
        </keywords>
        <abstract><p>This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.</p><p> This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header.</p></abstract>
        <draft>draft-ietf-core-stateless-08</draft>
        <updates>
            <doc-id>RFC7252</doc-id>
            <doc-id>RFC8323</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC8974</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8975</doc-id>
        <title>Network Coding for Satellite Systems</title>
        <author>
            <name>N. Kuhn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Lochin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>SATCOM</kw>
            <kw>coding techniques</kw>
        </keywords>
        <abstract><p>This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy (RFC 8406).</p><p> The objective is to contribute to a larger deployment of Network Coding techniques in and above the network layer in satellite communication systems. This document also identifies open research issues related to the deployment of Network Coding in satellite communication systems.</p></abstract>
        <draft>draft-irtf-nwcrg-network-coding-satellites-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC8975</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8976</doc-id>
        <title>Message Digest for DNS Zones</title>
        <author>
            <name>D. Wessels</name>
        </author>
        <author>
            <name>P. Barber</name>
        </author>
        <author>
            <name>M. Weinberg</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DNSSEC</kw>
            <kw>Checksum</kw>
            <kw>Hash</kw>
            <kw>Zone Transfer</kw>
        </keywords>
        <abstract><p>This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.</p><p> ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.</p><p> As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.</p></abstract>
        <draft>draft-ietf-dnsop-dns-zone-digest-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8976</errata-url>
        <doi>10.17487/RFC8976</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8977</doc-id>
        <title>Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging</title>
        <author>
            <name>M. Loffredo</name>
        </author>
        <author>
            <name>M. Martinelli</name>
        </author>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>Sorting</kw>
            <kw>Paging</kw>
        </keywords>
        <abstract><p>The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets.  This omission can lead to unpredictable server processing of queries and client processing of responses.  This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses.  This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets.</p></abstract>
        <draft>draft-ietf-regext-rdap-sorting-and-paging-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8977</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8978</doc-id>
        <title>Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>J. Žorž</name>
        </author>
        <author>
            <name>R. Patterson</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems.  This document describes this issue and discusses operational workarounds that may help to improve network robustness.  Additionally, it highlights areas where further work may be needed.</p></abstract>
        <draft>draft-ietf-v6ops-slaac-renum-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC8978</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8979</doc-id>
        <title>Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)</title>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>D. von Hugo</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>subscriber policy</kw>
            <kw>policy enforcement</kw>
            <kw>subscriber</kw>
            <kw>policy</kw>
            <kw>quota</kw>
            <kw>identification</kw>
            <kw>implicit identification</kw>
            <kw>service chain</kw>
            <kw>service function chain</kw>
            <kw>sfc</kw>
            <kw>SFP</kw>
            <kw>service function path</kw>
            <kw>classification</kw>
            <kw>5G</kw>
            <kw>traffic steering</kw>
        </keywords>
        <abstract><p>This document defines the Subscriber and Performance Policy Identifier Context Headers.  These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriate Service Function Chaining (SFC) operations.  The structure of each Context Header and their use and processing by NSH-aware nodes are described.</p></abstract>
        <draft>draft-ietf-sfc-serviceid-header-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC8979</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8980</doc-id>
        <title>Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-dedr-report-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC8980</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8981</doc-id>
        <title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>R. Draves</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>privacy</kw>
            <kw>anonymity</kw>
            <kw>unlinkability</kw>
            <kw>crypto-based address changing</kw>
        </keywords>
        <abstract><p>This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled.  Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host.  Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication.  This document obsoletes RFC 4941.</p></abstract>
        <draft>draft-ietf-6man-rfc4941bis-12</draft>
        <obsoletes>
            <doc-id>RFC4941</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC8981</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8982</doc-id>
        <title>Registration Data Access Protocol (RDAP) Partial Response</title>
        <author>
            <name>M. Loffredo</name>
        </author>
        <author>
            <name>M. Martinelli</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>Partial response</kw>
        </keywords>
        <abstract><p>The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  Servers will only return full responses that include all of the information that a client is authorized to receive.  A partial response capability that limits the amount of information returned, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.</p></abstract>
        <draft>draft-ietf-regext-rdap-partial-response-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC8982</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8983</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv4 service continuity</kw>
            <kw>VoLTE</kw>
            <kw>Handover</kw>
            <kw>Service continuity</kw>
            <kw>3GPP</kw>
            <kw>IPv6 transition</kw>
            <kw>TS.24302</kw>
            <kw>PDP context</kw>
            <kw>PDP type</kw>
        </keywords>
        <abstract><p>This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed.</p><p> This document updates RFC 7296.</p></abstract>
        <draft>draft-ietf-ipsecme-ipv6-ipv4-codes-06</draft>
        <updates>
            <doc-id>RFC7296</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC8983</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8984</doc-id>
        <title>JSCalendar: A JSON Representation of Calendar Data</title>
        <author>
            <name>N. Jenkins</name>
        </author>
        <author>
            <name>R. Stepanek</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>iCalendar</kw>
            <kw>calendar</kw>
            <kw>events</kw>
            <kw>date</kw>
            <kw>time</kw>
        </keywords>
        <abstract><p>This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment.  It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format.  It also aims to be unambiguous, extendable, and simple to process.  In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate.</p></abstract>
        <draft>draft-ietf-calext-jscalendar-32</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8984</errata-url>
        <doi>10.17487/RFC8984</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8985</doc-id>
        <title>The RACK-TLP Loss Detection Algorithm for TCP</title>
        <author>
            <name>Y. Cheng</name>
        </author>
        <author>
            <name>N. Cardwell</name>
        </author>
        <author>
            <name>N. Dukkipati</name>
        </author>
        <author>
            <name>P. Jha</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>Loss Recovery</kw>
            <kw>Reordering</kw>
        </keywords>
        <abstract><p>This document presents the RACK-TLP loss detection algorithm for TCP.  RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts.  Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events.  Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events.  It is intended to be an alternative to the DupAck threshold approach.</p></abstract>
        <draft>draft-ietf-tcpm-rack-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC8985</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8986</doc-id>
        <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Leddy</name>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>SRv6</kw>
            <kw>Segment Routing</kw>
            <kw>IPv6 Segment Routing</kw>
        </keywords>
        <abstract><p>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</p><p> Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</p><p> This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</p></abstract>
        <draft>draft-ietf-spring-srv6-network-programming-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8986</errata-url>
        <doi>10.17487/RFC8986</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8987</doc-id>
        <title>DHCPv6 Prefix Delegating Relay Requirements</title>
        <author>
            <name>I. Farrer</name>
        </author>
        <author>
            <name>N. Kottapalli</name>
        </author>
        <author>
            <name>M. Hunek</name>
        </author>
        <author>
            <name>R. Patterson</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Prefix Delegation</kw>
            <kw>DHCPv6 relay</kw>
            <kw>Delegating router</kw>
            <kw>Requesting router</kw>
            <kw>Delegating relay</kw>
        </keywords>
        <abstract><p>This document describes operational problems that are known to occur when using DHCPv6 relays with prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.</p><p> It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-pd-relay-requirements-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC8987</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC8988</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC8989</doc-id>
        <title>Additional Criteria for Nominating Committee Eligibility</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>February</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee.  It therefore also updates the criteria for qualifying signatories to a community recall petition.  The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings.  The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021.  This document temporarily varies the rules in RFC 8713.</p></abstract>
        <draft>draft-carpenter-eligibility-expand-10</draft>
        <obsoleted-by>
            <doc-id>RFC9389</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC8989</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8990</doc-id>
        <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Liu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>autonomic networking</kw>
            <kw>autonomous operation</kw>
            <kw>self-management</kw>
        </keywords>
        <abstract><p>This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other.  GRASP depends on an external security environment that is described elsewhere.  The technical objectives and parameters for specific application scenarios are to be described in separate documents.  Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.</p></abstract>
        <draft>draft-ietf-anima-grasp-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <doi>10.17487/RFC8990</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8991</doc-id>
        <title>GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>B. Liu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Wang</name>
        </author>
        <author>
            <name>X. Gong</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Autonomic Networking</kw>
            <kw>Autonomous Operation</kw>
            <kw>Self-Management</kw>
        </keywords>
        <abstract><p>This document is a conceptual outline of an Application Programming Interface (API) for the GeneRic Autonomic Signaling Protocol (GRASP).  Such an API is needed for Autonomic Service Agents (ASAs) calling the GRASP protocol module to exchange Autonomic Network messages with other ASAs.  Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems.</p></abstract>
        <draft>draft-ietf-anima-grasp-api-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <doi>10.17487/RFC8991</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8992</doc-id>
        <title>Autonomic IPv6 Edge Prefix Management in Large-Scale Networks</title>
        <author>
            <name>S. Jiang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Du</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>Q. Sun</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Autonomic Networking</kw>
            <kw>Prefix Management</kw>
        </keywords>
        <abstract><p>This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes.  An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure.</p></abstract>
        <draft>draft-ietf-anima-prefix-management-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8992</errata-url>
        <doi>10.17487/RFC8992</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8993</doc-id>
        <title>A Reference Model for Autonomic Networking</title>
        <author>
            <name>M. Behringer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <author>
            <name>L. Ciavaglia</name>
        </author>
        <author>
            <name>J. Nobre</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>autonomic networking</kw>
            <kw>autonomous operation</kw>
            <kw>self-management</kw>
            <kw>infrastructure</kw>
            <kw>intent</kw>
            <kw>autonomic control plane</kw>
        </keywords>
        <abstract><p>This document describes a reference model for Autonomic Networking for managed networks.  It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.</p></abstract>
        <draft>draft-ietf-anima-reference-model-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <doi>10.17487/RFC8993</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8994</doc-id>
        <title>An Autonomic Control Plane (ACP)</title>
        <author>
            <name>T. Eckert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Behringer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bjarnason</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>128</page-count>
        <keywords>
            <kw>addressing-scheme</kw>
            <kw>ANI</kw>
            <kw>autonomic networking</kw>
            <kw>autonomous operation</kw>
            <kw>BRSKI</kw>
            <kw>certificate</kw>
            <kw>Data-Plane</kw>
            <kw>domain</kw>
            <kw>DTLS</kw>
            <kw>DULL</kw>
            <kw>EST</kw>
            <kw>GRASP</kw>
            <kw>IDevID</kw>
            <kw>inband</kw>
            <kw>IPsec</kw>
            <kw>IPv6</kw>
            <kw>LDevID</kw>
            <kw>loopback-interface</kw>
            <kw>NOC</kw>
            <kw>OAM</kw>
            <kw>out-of-band</kw>
            <kw>registrar</kw>
            <kw>renewal</kw>
            <kw>RPL</kw>
            <kw>secure</kw>
            <kw>self-management</kw>
            <kw>ULA</kw>
            <kw>VPN</kw>
            <kw>VRF</kw>
        </keywords>
        <abstract><p>Autonomic functions need a control plane to communicate, which depends on some addressing and routing.  This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration.  This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions.  It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.</p></abstract>
        <draft>draft-ietf-anima-autonomic-control-plane-30</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8994</errata-url>
        <doi>10.17487/RFC8994</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8995</doc-id>
        <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
        <author>
            <name>M. Pritikin</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <author>
            <name>M. Behringer</name>
        </author>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>116</page-count>
        <keywords>
            <kw>Autonomic Networking</kw>
            <kw>Autonomous Operation</kw>
            <kw>Self-Management</kw>
            <kw>voucher-request</kw>
            <kw>onboarding</kw>
            <kw>zero-touch</kw>
            <kw>voucher</kw>
            <kw>RFC8366 voucher</kw>
            <kw>IoT-onboarding</kw>
            <kw>IoT-zero-touch</kw>
            <kw>network-join</kw>
        </keywords>
        <abstract><p>This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this, a Secure Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.  We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.  Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks.  Support for deployment models with less stringent security requirements is included.  Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.</p></abstract>
        <draft>draft-ietf-anima-bootstrapping-keyinfra-45</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8995</errata-url>
        <doi>10.17487/RFC8995</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8996</doc-id>
        <title>Deprecating TLS 1.0 and TLS 1.1</title>
        <author>
            <name>K. Moriarty</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>deprecate</kw>
            <kw>TLSv1.0</kw>
            <kw>TLSv1.1</kw>
        </keywords>
        <abstract><p>This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.</p><p> This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</p><p> This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</p></abstract>
        <draft>draft-ietf-tls-oldversions-deprecate-12</draft>
        <obsoletes>
            <doc-id>RFC5469</doc-id>
            <doc-id>RFC7507</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3329</doc-id>
            <doc-id>RFC3436</doc-id>
            <doc-id>RFC3470</doc-id>
            <doc-id>RFC3501</doc-id>
            <doc-id>RFC3552</doc-id>
            <doc-id>RFC3568</doc-id>
            <doc-id>RFC3656</doc-id>
            <doc-id>RFC3749</doc-id>
            <doc-id>RFC3767</doc-id>
            <doc-id>RFC3856</doc-id>
            <doc-id>RFC3871</doc-id>
            <doc-id>RFC3887</doc-id>
            <doc-id>RFC3903</doc-id>
            <doc-id>RFC3943</doc-id>
            <doc-id>RFC3983</doc-id>
            <doc-id>RFC4097</doc-id>
            <doc-id>RFC4111</doc-id>
            <doc-id>RFC4162</doc-id>
            <doc-id>RFC4168</doc-id>
            <doc-id>RFC4217</doc-id>
            <doc-id>RFC4235</doc-id>
            <doc-id>RFC4261</doc-id>
            <doc-id>RFC4279</doc-id>
            <doc-id>RFC4497</doc-id>
            <doc-id>RFC4513</doc-id>
            <doc-id>RFC4531</doc-id>
            <doc-id>RFC4540</doc-id>
            <doc-id>RFC4582</doc-id>
            <doc-id>RFC4616</doc-id>
            <doc-id>RFC4642</doc-id>
            <doc-id>RFC4680</doc-id>
            <doc-id>RFC4681</doc-id>
            <doc-id>RFC4712</doc-id>
            <doc-id>RFC4732</doc-id>
            <doc-id>RFC4743</doc-id>
            <doc-id>RFC4744</doc-id>
            <doc-id>RFC4785</doc-id>
            <doc-id>RFC4791</doc-id>
            <doc-id>RFC4823</doc-id>
            <doc-id>RFC4851</doc-id>
            <doc-id>RFC4964</doc-id>
            <doc-id>RFC4975</doc-id>
            <doc-id>RFC4976</doc-id>
            <doc-id>RFC4992</doc-id>
            <doc-id>RFC5018</doc-id>
            <doc-id>RFC5019</doc-id>
            <doc-id>RFC5023</doc-id>
            <doc-id>RFC5024</doc-id>
            <doc-id>RFC5049</doc-id>
            <doc-id>RFC5054</doc-id>
            <doc-id>RFC5091</doc-id>
            <doc-id>RFC5158</doc-id>
            <doc-id>RFC5216</doc-id>
            <doc-id>RFC5238</doc-id>
            <doc-id>RFC5263</doc-id>
            <doc-id>RFC5281</doc-id>
            <doc-id>RFC5364</doc-id>
            <doc-id>RFC5415</doc-id>
            <doc-id>RFC5422</doc-id>
            <doc-id>RFC5456</doc-id>
            <doc-id>RFC5734</doc-id>
            <doc-id>RFC5878</doc-id>
            <doc-id>RFC5953</doc-id>
            <doc-id>RFC6012</doc-id>
            <doc-id>RFC6042</doc-id>
            <doc-id>RFC6083</doc-id>
            <doc-id>RFC6084</doc-id>
            <doc-id>RFC6176</doc-id>
            <doc-id>RFC6347</doc-id>
            <doc-id>RFC6353</doc-id>
            <doc-id>RFC6367</doc-id>
            <doc-id>RFC6460</doc-id>
            <doc-id>RFC6614</doc-id>
            <doc-id>RFC6739</doc-id>
            <doc-id>RFC6749</doc-id>
            <doc-id>RFC6750</doc-id>
            <doc-id>RFC7030</doc-id>
            <doc-id>RFC7465</doc-id>
            <doc-id>RFC7525</doc-id>
            <doc-id>RFC7562</doc-id>
            <doc-id>RFC7568</doc-id>
            <doc-id>RFC8261</doc-id>
            <doc-id>RFC8422</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0195</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc8996</errata-url>
        <doi>10.17487/RFC8996</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8997</doc-id>
        <title>Deprecation of TLS 1.1 for Email Submission and Access</title>
        <author>
            <name>L. Velvindron</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This specification updates the current recommendation for the use of the Transport Layer Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server.  This document updates RFC 8314.</p></abstract>
        <draft>draft-ietf-uta-tls-for-email-05</draft>
        <updates>
            <doc-id>RFC8314</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <doi>10.17487/RFC8997</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8998</doc-id>
        <title>ShangMi (SM) Cipher Suites for TLS 1.3</title>
        <author>
            <name>P. Yang</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>cryptography</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
            <kw>network security</kw>
        </keywords>
        <abstract><p>This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3.</p><p> The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations.</p></abstract>
        <draft>draft-yang-tls-tls13-sm-suites-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC8998</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC8999</doc-id>
        <title>Version-Independent Properties of QUIC</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>crypto</kw>
            <kw>next generation</kw>
            <kw>protocol</kw>
            <kw>secure</kw>
            <kw>transport</kw>
            <kw>UDP</kw>
            <kw>invariants</kw>
        </keywords>
        <abstract><p>This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.</p></abstract>
        <draft>draft-ietf-quic-invariants-13</draft>
        <updated-by>
            <doc-id>RFC9368</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <doi>10.17487/RFC8999</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9000</doc-id>
        <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
        <author>
            <name>J. Iyengar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Thomson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>151</page-count>
        <keywords>
            <kw>multipath</kw>
            <kw>next generations</kw>
            <kw>protocol</kw>
            <kw>sctp++</kw>
            <kw>secure</kw>
            <kw>smart</kw>
            <kw>tcp/2</kw>
            <kw>tcpng</kw>
            <kw>transport</kw>
            <kw>transport-ng</kw>
        </keywords>
        <abstract><p>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration.  QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</p></abstract>
        <draft>draft-ietf-quic-transport-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9000</errata-url>
        <doi>10.17487/RFC9000</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9001</doc-id>
        <title>Using TLS to Secure QUIC</title>
        <author>
            <name>M. Thomson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Turner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>crypto</kw>
            <kw>opportunistic encryption</kw>
            <kw>plaintext quic</kw>
        </keywords>
        <abstract><p>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</p></abstract>
        <draft>draft-ietf-quic-tls-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9001</errata-url>
        <doi>10.17487/RFC9001</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9002</doc-id>
        <title>QUIC Loss Detection and Congestion Control</title>
        <author>
            <name>J. Iyengar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Swett</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>bbr</kw>
            <kw>delay-sensitive congestion control</kw>
            <kw>fec</kw>
            <kw>loss-tolerant congestion control</kw>
            <kw>next generation</kw>
        </keywords>
        <abstract><p>This document describes loss detection and congestion control mechanisms for QUIC.</p></abstract>
        <draft>draft-ietf-quic-recovery-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9002</errata-url>
        <doi>10.17487/RFC9002</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9003</doc-id>
        <title>Extended BGP Administrative Shutdown Communication</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>J. Heitz</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>A. Azimov</name>
        </author>
        <date>
            <month>January</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>cease</kw>
            <kw>shutdown</kw>
        </keywords>
        <abstract><p>This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short free-form message to describe why a BGP session was shut down or reset.  This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication of up to 255 octets to improve communication using multibyte character sets.</p></abstract>
        <draft>draft-ietf-idr-rfc8203bis-08</draft>
        <obsoletes>
            <doc-id>RFC8203</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4486</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9003</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9004</doc-id>
        <title>Updates for the Back-to-Back Frame Benchmark in RFC 2544</title>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Buffer size</kw>
            <kw>Buffer delay</kw>
            <kw>Correction Factor</kw>
        </keywords>
        <abstract><p>Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience.</p><p> This memo updates Section 26.4 of RFC 2544.</p></abstract>
        <draft>draft-ietf-bmwg-b2b-frame-04</draft>
        <updates>
            <doc-id>RFC2544</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC9004</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9005</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs)</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>J. Hardwick</name>
        </author>
        <author>
            <name>C. Li</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Association</kw>
            <kw>Policy</kw>
        </keywords>
        <abstract><p>This document introduces a simple mechanism to associate policies with a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP).  The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group (PAG).</p></abstract>
        <draft>draft-ietf-pce-association-policy-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9005</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9006</doc-id>
        <title>TCP Usage Guidance in the Internet of Things (IoT)</title>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <author>
            <name>M. Scharf</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>constrained node networks</kw>
            <kw>CNNs</kw>
            <kw>HTTP</kw>
            <kw>CoAP</kw>
            <kw>MQTT</kw>
            <kw>6LoWPAN</kw>
            <kw>6Lo</kw>
            <kw>IEEE 802.15.4</kw>
            <kw>Bluetooth Low Energy</kw>
            <kw>Contiki</kw>
            <kw>uIP</kw>
        </keywords>
        <abstract><p>This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT).  Such environments require a lightweight TCP implementation and may not make use of optional functionality.  This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs.  The objective is to help embedded developers with decisions on which TCP features to use.</p></abstract>
        <draft>draft-ietf-lwig-tcp-constrained-node-networks-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC9006</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9007</doc-id>
        <title>Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)</title>
        <author>
            <name>R. Ouazana</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
            <kw>email</kw>
            <kw>MDN</kw>
        </keywords>
        <abstract><p>This document specifies a data model for handling Message Disposition Notifications (MDNs) (see RFC 8098) in the JSON Meta Application Protocol (JMAP) (see RFCs 8620 and 8621).</p></abstract>
        <draft>draft-ietf-jmap-mdn-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9007</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9008</doc-id>
        <title>Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane</title>
        <author>
            <name>M.I. Robles</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>RPL Option</kw>
            <kw>6LoWPAN</kw>
            <kw>RFC 6553</kw>
        </keywords>
        <abstract><p>This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing.  The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane.  This analysis provides the basis upon which to design efficient compression of these headers.  This document updates RFC 6553 by adding a change to the RPI Option Type.  Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.</p></abstract>
        <draft>draft-ietf-roll-useofrplinfo-44</draft>
        <updates>
            <doc-id>RFC6553</doc-id>
            <doc-id>RFC6550</doc-id>
            <doc-id>RFC8138</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9008</errata-url>
        <doi>10.17487/RFC9008</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9009</doc-id>
        <title>Efficient Route Invalidation</title>
        <author>
            <name>R.A. Jadhav</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>R.N. Sahoo</name>
        </author>
        <author>
            <name>Z. Cao</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>NPDAO</kw>
            <kw>DCO</kw>
            <kw>no-path</kw>
            <kw>route</kw>
            <kw>cleanup</kw>
        </keywords>
        <abstract><p>This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme.  Further, this document specifies a new proactive route invalidation message called the "Destination Cleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging.</p></abstract>
        <draft>draft-ietf-roll-efficient-npdao-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC9009</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9010</doc-id>
        <title>Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>ND</kw>
            <kw>Redistribution</kw>
        </keywords>
        <abstract><p>This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations.  It updates RFCs 6550, 6775, and 8505.</p></abstract>
        <draft>draft-ietf-roll-unaware-leaves-30</draft>
        <updates>
            <doc-id>RFC6550</doc-id>
            <doc-id>RFC6775</doc-id>
            <doc-id>RFC8505</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9685</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9010</errata-url>
        <doi>10.17487/RFC9010</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9011</doc-id>
        <title>Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN</title>
        <author>
            <name>O. Gimenez</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Petrov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>header compression</kw>
            <kw>compression</kw>
            <kw>fragmentation</kw>
            <kw>static context</kw>
            <kw>rule-based</kw>
            <kw>LPWAN</kw>
            <kw>LPWANs</kw>
            <kw>low power</kw>
            <kw>low-power</kw>
            <kw>LoRa</kw>
            <kw>LoRaWAN</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>adaptation layer</kw>
            <kw>UDP</kw>
            <kw>IPv6</kw>
            <kw>sensor network</kw>
            <kw>wireless sensor network</kw>
            <kw>802.15.4</kw>
            <kw>constrained network</kw>
            <kw>constrained node</kw>
            <kw>constrained-node network</kw>
            <kw>SCHC</kw>
        </keywords>
        <abstract><p>The Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.</p><p> This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation.</p></abstract>
        <draft>draft-ietf-lpwan-schc-over-lorawan-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC9011</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9012</doc-id>
        <title>The BGP Tunnel Encapsulation Attribute</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>S. Sangli</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.</p><p> This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.</p></abstract>
        <draft>draft-ietf-idr-tunnel-encaps-22</draft>
        <obsoletes>
            <doc-id>RFC5512</doc-id>
            <doc-id>RFC5566</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5640</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9012</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9013</doc-id>
        <title>OSPF Advertisement of Tunnel Encapsulations</title>
        <author>
            <name>X. Xu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>L. Contreras</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>Networks use tunnels for a variety of reasons.  A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router.  This document defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator.</p></abstract>
        <draft>draft-ietf-ospf-encapsulation-cap-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ospf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9013</errata-url>
        <doi>10.17487/RFC9013</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9014</doc-id>
        <title>Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>DCI</kw>
            <kw>UMR</kw>
            <kw>Unknown MAC Route</kw>
            <kw>I-ES</kw>
            <kw>I-ESI</kw>
        </keywords>
        <abstract><p>This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend the Layer 2 connectivity required for some tenants.  The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN, or PBB-EVPN.  It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases.  In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES), to provide multihoming.  This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data Center Network Virtualization Edge (NVE) devices.</p></abstract>
        <draft>draft-ietf-bess-dci-evpn-overlay-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9014</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9015</doc-id>
        <title>BGP Control Plane for the Network Service Header in Service Function Chaining</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>Service Function Chaining</kw>
            <kw>Service Function Chain</kw>
            <kw>Network Service Header</kw>
            <kw>Service Function</kw>
            <kw> Service Function Forwarder</kw>
            <kw>Service Function Path</kw>
            <kw>Service Function Path Route</kw>
            <kw>Service Function Instance</kw>
            <kw>Service Function Instance Route</kw>
            <kw>Service Function Type</kw>
            <kw>Control Plane</kw>
        </keywords>
        <abstract><p>This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) defined in RFC 8300.</p><p> This document adopts the service function chaining architecture described in RFC 7665.</p></abstract>
        <draft>draft-ietf-bess-nsh-bgp-control-plane-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9015</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9016</doc-id>
        <title>Flow and Service Information Model for Deterministic Networking (DetNet)</title>
        <author>
            <name>B. Varga</name>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>R. Cummings</name>
        </author>
        <author>
            <name>Y. Jiang</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <date>
            <month>March</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>DetNet</kw>
            <kw>Flow and Service Information Model</kw>
        </keywords>
        <abstract><p>This document describes the flow and service information model for Deterministic Networking (DetNet).  These models are defined for IP and MPLS DetNet data planes.</p></abstract>
        <draft>draft-ietf-detnet-flow-information-model-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9016</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9017</doc-id>
        <title>Special-Purpose Label Terminology</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>Extended Special-Purpose Label</kw>
            <kw>Base Special-Purpose Label</kw>
            <kw>Reserved Label</kw>
            <kw>Entropy Label Indicator</kw>
        </keywords>
        <abstract><p>This document discusses and recommends terminology that may be used when MPLS Special-Purpose Labels (SPLs) are specified and documented.</p><p> This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator (7) when immediately preceded by the Extension Label (15).</p><p> This document updates RFCs 3032 and 7274.</p></abstract>
        <draft>draft-ietf-mpls-spl-terminology-06</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
            <doc-id>RFC7274</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9017</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9018</doc-id>
        <title>Interoperable Domain Name System (DNS) Server Cookies</title>
        <author>
            <name>O. Sury</name>
        </author>
        <author>
            <name>W. Toorop</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>M. Andrews</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Client</kw>
            <kw>Hash</kw>
        </keywords>
        <abstract><p>DNS Cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service amplification, forgery, or cache-poisoning attacks by off-path attackers.</p><p> This document updates RFC 7873 with precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, with suggestions for constructing Client Cookies in a privacy-preserving fashion, and with suggestions on how to update a Server Secret. An IANA registry listing the methods and associated pseudorandom function suitable for creating DNS Server Cookies has been created with the method described in this document as the first and, as of the time of publication, only entry.</p></abstract>
        <draft>draft-ietf-dnsop-server-cookies-05</draft>
        <updates>
            <doc-id>RFC7873</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9018</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9019</doc-id>
        <title>A Firmware Update Architecture for Internet of Things</title>
        <author>
            <name>B. Moran</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <author>
            <name>M. Meriac</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>update</kw>
            <kw>software</kw>
            <kw>firmware</kw>
            <kw>constrained</kw>
            <kw>Secure</kw>
            <kw>Boot</kw>
        </keywords>
        <abstract><p>Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.</p><p> In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.</p></abstract>
        <draft>draft-ietf-suit-architecture-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>suit</wg_acronym>
        <doi>10.17487/RFC9019</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9020</doc-id>
        <title>YANG Data Model for Segment Routing</title>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>P. Sarkar</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>mpls</kw>
        </keywords>
        <abstract><p>This document defines three YANG data models.  The first is for Segment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes.  The next is a YANG data model that defines a collection of generic types and groupings for SR.  The third module defines the configuration and operational states for the Segment Routing MPLS data plane.</p></abstract>
        <draft>draft-ietf-spring-sr-yang-30</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9020</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9021</doc-id>
        <title>Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)</title>
        <author>
            <name>D. Atkins</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>COSE</kw>
            <kw>WalnutDSA</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on Group Theoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms.</p><p> The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties of WalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF.</p><p> WalnutDSA and the Walnut Digital Signature Algorithm are trademarks of Veridify Security Inc.</p></abstract>
        <draft>draft-atkins-suit-cose-walnutdsa-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9021</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9022</doc-id>
        <title>Domain Name Registration Data (DNRD) Objects Mapping</title>
        <author>
            <name>G. Lozano</name>
        </author>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>C. Thippeswamy</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>169</page-count>
        <keywords>
            <kw>data escrow</kw>
            <kw>registry</kw>
            <kw>domain name</kw>
            <kw>domain name registration data</kw>
        </keywords>
        <abstract><p>This document specifies the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.</p></abstract>
        <draft>draft-ietf-regext-dnrd-objects-mapping-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9022</errata-url>
        <doi>10.17487/RFC9022</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9023</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network.  This document does not define new procedures or processes.  Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs.</p></abstract>
        <draft>draft-ietf-detnet-ip-over-tsn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9023</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9024</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>interconnecting TSN networks</kw>
        </keywords>
        <abstract><p>This document specifies the Deterministic Networking data plane when Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS network.</p></abstract>
        <draft>draft-ietf-detnet-tsn-vpn-over-mpls-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9024</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9025</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network.  The approach is based on the operation of MPLS-over-UDP technology.</p></abstract>
        <draft>draft-ietf-detnet-mpls-over-udp-ip-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9025</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9026</doc-id>
        <title>Multicast VPN Fast Upstream Failover</title>
        <author>
            <name>T. Morin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Kebler</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>P2MP</kw>
        </keywords>
        <abstract><p>This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow.  The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator.  Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.</p></abstract>
        <draft>draft-ietf-bess-mvpn-fast-failover-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9026</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9027</doc-id>
        <title>Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks</title>
        <author>
            <name>M. Dolly</name>
        </author>
        <author>
            <name>C. Wendt</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>rph</kw>
            <kw>PASSport</kw>
            <kw>esnet</kw>
        </keywords>
        <abstract><p>This document adds new assertion values for a Resource Priority Header ("rph") claim and a new SIP Priority Header ("sph") claim for protection of the "psap-callback" value as part of the "rph" Personal Assertion Token (PASSporT) extension in support of the security of emergency services networks for emergency call origination and callback.</p></abstract>
        <draft>draft-ietf-stir-rph-emergency-services-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC9027</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9028</doc-id>
        <title>Native NAT Traversal Mode for the Host Identity Protocol</title>
        <author>
            <name>A. Keränen</name>
        </author>
        <author>
            <name>J. Melén</name>
        </author>
        <author>
            <name>M. Komu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>HIP</kw>
            <kw>NAT</kw>
            <kw>NAT traversal</kw>
        </keywords>
        <abstract><p>This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP).  The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic.  The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP.</p></abstract>
        <draft>draft-ietf-hip-native-nat-traversal-33</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC9028</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9029</doc-id>
        <title>Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS). IANA created a registry consistent with that document called "Border Gateway Protocol - Link State (BGP-LS) Parameters" with a number of subregistries. The allocation policy applied by IANA for those registries is "Specification Required", as defined in RFC 8126.</p><p> This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the designated experts.</p></abstract>
        <draft>draft-ietf-idr-bgp-ls-registry-06</draft>
        <obsoleted-by>
            <doc-id>RFC9552</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC7752</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9029</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9030</doc-id>
        <title>An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>deterministic wireless</kw>
            <kw>radio</kw>
            <kw>mesh</kw>
        </keywords>
        <abstract><p>This document describes a network architecture that provides low-latency, low-jitter, and high-reliability packet delivery.  It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications.</p></abstract>
        <draft>draft-ietf-6tisch-architecture-30</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <doi>10.17487/RFC9030</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9031</doc-id>
        <title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
        <author>
            <name>M. Vučinić</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Simon</name>
        </author>
        <author>
            <name>K. Pister</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>bootstrapping</kw>
            <kw>onboarding</kw>
            <kw>oscore</kw>
        </keywords>
        <abstract><p>This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network.  The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key.  How this key is provisioned is out of scope of this document.  Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters.  The JRC may at any time update the parameters through another request-response exchange secured by OSCORE.  This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner.  Additional security mechanisms may be added on top of this minimal framework.</p></abstract>
        <draft>draft-ietf-6tisch-minimal-security-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <doi>10.17487/RFC9031</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9032</doc-id>
        <title>Encapsulation of 6TiSCH Join and Enrollment Information Elements</title>
        <author>
            <name>D. Dujovne</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>BRSKI</kw>
            <kw>enroll</kw>
            <kw>zero-touch</kw>
            <kw>DODAG balancing</kw>
            <kw>LLN balancing</kw>
        </keywords>
        <abstract><p>In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels.  Routers in a TSCH network transmit Enhanced Beacon (EB) frames to announce the presence of the network.  This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities.</p></abstract>
        <draft>draft-ietf-6tisch-enrollment-enhanced-beacon-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <doi>10.17487/RFC9032</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9033</doc-id>
        <title>6TiSCH Minimal Scheduling Function (MSF)</title>
        <author>
            <name>T. Chang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Vučinić</name>
        </author>
        <author>
            <name>X. Vilajosana</name>
        </author>
        <author>
            <name>S. Duquennoy</name>
        </author>
        <author>
            <name>D. Dujovne</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>TSCH</kw>
            <kw>communication schedule</kw>
            <kw>6P</kw>
        </keywords>
        <abstract><p>This specification defines the "IPv6 over the TSCH mode of IEEE 802.15.4" (6TiSCH) Minimal Scheduling Function (MSF).  This Scheduling Function describes both the behavior of a node when joining the network and how the communication schedule is managed in a distributed fashion.  MSF is built upon the 6TiSCH Operation Sublayer Protocol (6P) and the minimal security framework for 6TiSCH.</p></abstract>
        <draft>draft-ietf-6tisch-msf-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6tisch</wg_acronym>
        <doi>10.17487/RFC9033</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9034</doc-id>
        <title>Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
        <author>
            <name>L. Thomas</name>
        </author>
        <author>
            <name>S. Anamalamudi</name>
        </author>
        <author>
            <name>S.V.R. Anand</name>
        </author>
        <author>
            <name>M. Hegde</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Routing header</kw>
            <kw>Timestamp</kw>
        </keywords>
        <abstract><p>This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks.  The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks.  This document also specifies a representation for the deadline time values in such networks.</p></abstract>
        <draft>draft-ietf-6lo-deadline-time-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC9034</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9035</doc-id>
        <title>A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Zhao</name>
        </author>
        <date>
            <month>April</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>Header Compression</kw>
            <kw>Source Routing Header</kw>
            <kw>Hop-by-Hop Header</kw>
            <kw>RPL artifacts</kw>
        </keywords>
        <abstract><p>This document updates RFC 8138 by defining a bit in the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset.</p></abstract>
        <draft>draft-ietf-roll-turnon-rfc8138-18</draft>
        <updates>
            <doc-id>RFC8138</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>roll</wg_acronym>
        <doi>10.17487/RFC9035</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9036</doc-id>
        <title>Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>This document changes the policy of the "Location-to-Service Translation (LoST) Location Profiles" IANA registry established by RFC 5222 from Standards Action to Specification Required.  This allows standards development organizations (SDOs) other than the IETF to add new values.</p></abstract>
        <draft>draft-ietf-ecrit-location-profile-registry-policy-02</draft>
        <updates>
            <doc-id>RFC5222</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>ecrit</wg_acronym>
        <doi>10.17487/RFC9036</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9037</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>sub-network</kw>
            <kw>flow mapping</kw>
        </keywords>
        <abstract><p>This document specifies the Deterministic Networking (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-Sensitive Networking (TSN) sub-network.  This document does not define new procedures or processes.  Whenever this document makes statements or recommendations, they are taken from normative text in the referenced RFCs.</p></abstract>
        <draft>draft-ietf-detnet-mpls-over-tsn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9037</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9038</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Unhandled Namespaces</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>M. Casanova</name>
        </author>
        <date>
            <month>May</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>login</kw>
            <kw>greeting</kw>
            <kw>URI</kw>
            <kw>namespace</kw>
            <kw>response</kw>
            <kw>general</kw>
            <kw>poll</kw>
            <kw>object-level</kw>
            <kw>command-response</kw>
            <kw>signal</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract><p>The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session.  The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client.  This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730.</p></abstract>
        <draft>draft-ietf-regext-unhandled-namespaces-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9038</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9039</doc-id>
        <title>Uniform Resource Names for Device Identifiers</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>Z. Shelby</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>URN</kw>
            <kw>device identifier</kw>
            <kw>IMEI</kw>
            <kw>1-Wire</kw>
            <kw>MAC address</kw>
            <kw>EUI-48</kw>
            <kw>EUI-64</kw>
        </keywords>
        <abstract><p>This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers.  A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories.  A URN-based representation can be passed along in applications that need the information.</p></abstract>
        <draft>draft-ietf-core-dev-urn-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9039</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9040</doc-id>
        <title>TCP Control Block Interdependence</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <author>
            <name>S. Islam</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability.  It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCP Control Blocks, among similar concurrent or consecutive connections.</p></abstract>
        <draft>draft-ietf-tcpm-2140bis-11</draft>
        <obsoletes>
            <doc-id>RFC2140</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC9040</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9041</doc-id>
        <title>Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>T. Saad</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "Vendor Private Use") has been changed to "First Come First Served" for the TLV and sub-TLV registries.</p><p> It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoleted RFC 5226 (both titled "Guidelines for Writing an IANA Considerations Section in RFCs").</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-registries-update-11</draft>
        <updates>
            <doc-id>RFC8029</doc-id>
            <doc-id>RFC8611</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9041</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9042</doc-id>
        <title>Sieve Email Filtering: Delivery by MAILBOXID</title>
        <author>
            <name>B. Gondwana</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>sieve</kw>
            <kw>email</kw>
        </keywords>
        <abstract><p>The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming.</p><p> This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes.</p></abstract>
        <draft>draft-ietf-extra-sieve-mailboxid-09</draft>
        <updates>
            <doc-id>RFC5228</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9042</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9043</doc-id>
        <title>FFV1 Video Coding Format Versions 0, 1, and 3</title>
        <author>
            <name>M. Niedermayer</name>
        </author>
        <author>
            <name>D. Rice</name>
        </author>
        <author>
            <name>J. Martinez</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>video preservation</kw>
            <kw>storage</kw>
            <kw>ffmpeg</kw>
            <kw>lossless compression</kw>
        </keywords>
        <abstract><p>This document defines FFV1, a lossless, intra-frame video encoding format.  FFV1 is designed to efficiently compress video data in a variety of pixel formats.  Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.</p></abstract>
        <draft>draft-ietf-cellar-ffv1-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cellar</wg_acronym>
        <doi>10.17487/RFC9043</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9044</doc-id>
        <title>Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Authentication</kw>
            <kw>Message Authentication Code</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithm with the Cryptographic Message Syntax (CMS) as specified in RFC 5652.</p></abstract>
        <draft>draft-ietf-lamps-cms-aes-gmac-alg-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9044</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9045</doc-id>
        <title>Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Authentication</kw>
            <kw>Message Authentication Code</kw>
            <kw>Password-Based Message Authentication Code</kw>
        </keywords>
        <abstract><p>This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211.</p></abstract>
        <draft>draft-ietf-lamps-crmf-update-algs-07</draft>
        <updates>
            <doc-id>RFC4211</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9045</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9046</doc-id>
        <title>Babel Information Model</title>
        <author>
            <name>B. Stark</name>
        </author>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Babel</kw>
        </keywords>
        <abstract><p>The Babel information model provides structured data elements for a Babel implementation reporting its current state and may allow limited configuration of some such data elements.  This information model can be used as a basis for creating data models under various data modeling regimes.  This information model only includes parameters and parameter values useful for managing Babel over IPv6.</p></abstract>
        <draft>draft-ietf-babel-information-model-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC9046</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9047</doc-id>
        <title>Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <author>
            <name>K. Nagaraj</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>proxy-ARP</kw>
            <kw>proxy-ND</kw>
            <kw>proxy-ARP/ND</kw>
            <kw>ARP/ND extended community</kw>
        </keywords>
        <abstract><p>This document defines an Extended Community that is advertised along with an Ethernet Virtual Private Network (EVPN) Media Access Control (MAC) / IP Advertisement route and carries information relevant to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND function on Integrated Routing and Bridging (IRB) interfaces can reply to ARP Requests or Neighbor Solicitation (NS) messages with the correct information.</p></abstract>
        <draft>draft-ietf-bess-evpn-na-flags-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9047</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9048</doc-id>
        <title>Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>V. Lehtovirta</name>
        </author>
        <author>
            <name>V. Torvinen</name>
        </author>
        <author>
            <name>P. Eronen</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>AKA</kw>
            <kw>AKA'</kw>
            <kw>3GPP</kw>
        </keywords>
        <abstract><p>The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA.</p><p> This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.</p><p> EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.</p><p> This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448.</p></abstract>
        <draft>draft-ietf-emu-rfc5448bis-10</draft>
        <updates>
            <doc-id>RFC5448</doc-id>
            <doc-id>RFC4187</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9678</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC9048</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9049</doc-id>
        <title>Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)</title>
        <author>
            <name>S. Dawkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>PAN</kw>
        </keywords>
        <abstract><p>This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.</p><p> This document contains that catalog and analysis.</p></abstract>
        <draft>draft-irtf-panrg-what-not-to-do-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9049</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9050</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>S. Peng</name>
        </author>
        <author>
            <name>M. Negi</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>C. Zhou</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>SDN</kw>
            <kw>CCI</kw>
            <kw>Central Control</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.</p><p> A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.</p><p> This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP.</p></abstract>
        <draft>draft-ietf-pce-pcep-extension-for-pce-controller-14</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9050</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9051</doc-id>
        <title>Internet Message Access Protocol (IMAP) - Version 4rev2</title>
        <author>
            <name>A. Melnikov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Leiba</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>163</page-count>
        <keywords>
            <kw>IMAP4rev2</kw>
            <kw>imap</kw>
        </keywords>
        <abstract><p>The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.</p><p> IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.</p><p> IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.</p></abstract>
        <draft>draft-ietf-extra-imap4rev2-30</draft>
        <obsoletes>
            <doc-id>RFC3501</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9051</errata-url>
        <doi>10.17487/RFC9051</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9052</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>66</page-count>
        <keywords>
            <kw>Object Security</kw>
            <kw>COSE</kw>
            <kw>Constrained Devices</kw>
        </keywords>
        <abstract><p>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</p><p> This document, along with RFC 9053, obsoletes RFC 8152.</p></abstract>
        <draft>draft-ietf-cose-rfc8152bis-struct-15</draft>
        <obsoletes>
            <doc-id>RFC8152</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC9338</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0096</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC9052</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9053</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Object Security</kw>
            <kw>COSE</kw>
            <kw>Constrained Devices</kw>
            <kw>AES</kw>
            <kw>AES-GCM</kw>
            <kw>AES-CCM</kw>
            <kw>ECDSA</kw>
            <kw>EdDSA</kw>
            <kw>ECC</kw>
            <kw>HSS-LMS</kw>
            <kw>AES-KW</kw>
            <kw>ECDH</kw>
            <kw>HMAC</kw>
            <kw>CMAC</kw>
            <kw>Cryptography</kw>
        </keywords>
        <abstract><p>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</p><p> This document, along with RFC 9052, obsoletes RFC 8152.</p></abstract>
        <draft>draft-ietf-cose-rfc8152bis-algs-12</draft>
        <obsoletes>
            <doc-id>RFC8152</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9053</errata-url>
        <doi>10.17487/RFC9053</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9054</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): Hash Algorithms</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>SHA-1 Hash Algorithm</kw>
            <kw>SHA-2 Hash Algorithm</kw>
            <kw>SHAKE Algorithm</kw>
        </keywords>
        <abstract><p>The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms.  There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint.  This document defines hash algorithms that are identified by COSE algorithm identifiers.</p></abstract>
        <draft>draft-ietf-cose-hash-algs-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9054</errata-url>
        <doi>10.17487/RFC9054</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9055</doc-id>
        <title>Deterministic Networking (DetNet) Security Considerations</title>
        <author>
            <name>E. Grossman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>A. Hacker</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>DetNet</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.</p><p> This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.</p><p> This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.</p></abstract>
        <draft>draft-ietf-detnet-security-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9055</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9056</doc-id>
        <title>Deterministic Networking (DetNet) Data Plane: IP over MPLS</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>J. Korhonen</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>sub-network</kw>
            <kw>subnetwork</kw>
        </keywords>
        <abstract><p>This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network.</p></abstract>
        <draft>draft-ietf-detnet-ip-over-mpls-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9056</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9057</doc-id>
        <title>Email Author Header Field</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>domain</kw>
            <kw>email</kw>
            <kw>security</kw>
            <kw>messaging</kw>
            <kw>dkim</kw>
            <kw>spf</kw>
            <kw>authentication</kw>
            <kw>reporting</kw>
            <kw>conformance</kw>
            <kw>author</kw>
            <kw>origination</kw>
            <kw>original</kw>
            <kw>from</kw>
            <kw>sender</kw>
        </keywords>
        <abstract><p>Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field. This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier.</p><p> The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification by Mediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy.</p></abstract>
        <draft>draft-crocker-email-author-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9057</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9058</doc-id>
        <title>Multilinear Galois Mode (MGM)</title>
        <author>
            <name>S. Smyshlyaev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Nozdrunov</name>
        </author>
        <author>
            <name>V. Shishkin</name>
        </author>
        <author>
            <name>E. Griboedova</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>authenticated encryption</kw>
            <kw>mode of operation</kw>
            <kw>AEAD</kw>
        </keywords>
        <abstract><p>Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers.</p><p> MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher.</p></abstract>
        <draft>draft-smyshlyaev-mgm-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9058</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9059</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Barth</name>
        </author>
        <author>
            <name>B. Wen</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>RSVP-TE LSP</kw>
            <kw>Co-routed LSP</kw>
            <kw>Reverse LSP</kw>
        </keywords>
        <abstract><p>This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP.  These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE.  The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.</p></abstract>
        <draft>draft-ietf-pce-association-bidir-14</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9059</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9060</doc-id>
        <title>Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Secure Origin Identification</kw>
            <kw>Communication Security</kw>
            <kw>Certificates</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>Real-Time Communication</kw>
        </keywords>
        <abstract><p>The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing.  This specification details how that authority can be delegated from a parent certificate to a subordinate certificate.  This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.</p></abstract>
        <draft>draft-ietf-stir-cert-delegation-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC9060</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9061</doc-id>
        <title>A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)</title>
        <author>
            <name>R. Marin-Lopez</name>
        </author>
        <author>
            <name>G. Lopez-Millan</name>
        </author>
        <author>
            <name>F. Pereniguez-Garcia</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>90</page-count>
        <keywords>
            <kw>NSF</kw>
            <kw>SDN</kw>
            <kw>IPsec</kw>
        </keywords>
        <abstract><p>This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) Controller. It considers two main well-known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic.</p><p> This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.</p></abstract>
        <draft>draft-ietf-i2nsf-sdn-ipsec-flow-protection-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>i2nsf</wg_acronym>
        <doi>10.17487/RFC9061</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9062</doc-id>
        <title>Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)</title>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>PBB-EVPN</kw>
            <kw>fault management</kw>
            <kw>performance management</kw>
        </keywords>
        <abstract><p>This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM).  The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN).  The framework defines the layered OAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers.</p></abstract>
        <draft>draft-ietf-bess-evpn-oam-req-frmwk-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9062</errata-url>
        <doi>10.17487/RFC9062</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9063</doc-id>
        <title>Host Identity Protocol Architecture</title>
        <author>
            <name>R. Moskowitz</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Komu</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>cryptographic identity</kw>
            <kw>cryptographic namespace</kw>
            <kw>identifier-locator split</kw>
            <kw>mobility</kw>
            <kw>multihoming</kw>
            <kw>NAT traversal</kw>
            <kw>IPsec</kw>
            <kw>ESP</kw>
            <kw>IPv6</kw>
            <kw>end-to-end security</kw>
            <kw>end-to-end connectivity</kw>
            <kw>endpoint identity</kw>
            <kw>leap of faith</kw>
            <kw>rendezvous</kw>
        </keywords>
        <abstract><p>This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined.</p><p> This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The Security Considerations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel.</p></abstract>
        <draft>draft-ietf-hip-rfc4423-bis-20</draft>
        <obsoletes>
            <doc-id>RFC4423</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>hip</wg_acronym>
        <doi>10.17487/RFC9063</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9064</doc-id>
        <title>Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols</title>
        <author>
            <name>D. Oran</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>ICN</kw>
            <kw>QoS</kw>
            <kw>congestion control</kw>
            <kw>admission control</kw>
        </keywords>
        <abstract><p>This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be assessed and controlled at the application layer or above.</p><p> This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.</p></abstract>
        <draft>draft-oran-icnrg-qosarch-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9064</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9065</doc-id>
        <title>Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>transport design</kw>
            <kw>operations and management</kw>
        </keywords>
        <abstract><p>To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted.</p><p> This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features.</p></abstract>
        <draft>draft-ietf-tsvwg-transport-encrypt-21</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9065</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9066</doc-id>
        <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home</title>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Shallow</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>Automation</kw>
            <kw>Anti-DDoS Automation</kw>
            <kw>DDoS Mitigation</kw>
            <kw>Collaborative Networking</kw>
            <kw>Protective Networking</kw>
            <kw>Security</kw>
            <kw>Scrubbing</kw>
        </keywords>
        <abstract><p>This document specifies the Denial-of-Service Open Threat Signaling (DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s).</p><p> The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack.</p></abstract>
        <draft>draft-ietf-dots-signal-call-home-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC9066</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9067</doc-id>
        <title>A YANG Data Model for Routing Policy</title>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <abstract><p>This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way.  The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.</p></abstract>
        <draft>draft-ietf-rtgwg-policy-model-31</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9067</errata-url>
        <doi>10.17487/RFC9067</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9068</doc-id>
        <title>JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens</title>
        <author>
            <name>V. Bertocci</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>Resource</kw>
            <kw>Access token</kw>
            <kw>JWT</kw>
        </keywords>
        <abstract><p>This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format.  Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.</p></abstract>
        <draft>draft-ietf-oauth-access-token-jwt-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9068</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9069</doc-id>
        <title>Support for Local RIB in the BGP Monitoring Protocol (BMP)</title>
        <author>
            <name>T. Evens</name>
        </author>
        <author>
            <name>S. Bayraktar</name>
        </author>
        <author>
            <name>M. Bhardwaj</name>
        </author>
        <author>
            <name>P. Lucente</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>BMP</kw>
            <kw>local-rib</kw>
            <kw>loc-rib</kw>
        </keywords>
        <abstract><p>The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs).  This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271.  The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.</p></abstract>
        <draft>draft-ietf-grow-bmp-local-rib-13</draft>
        <updates>
            <doc-id>RFC7854</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9736</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC9069</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9070</doc-id>
        <title>YANG Data Model for MPLS LDP</title>
        <author>
            <name>K. Raza</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>S. Esale</name>
        </author>
        <author>
            <name>X. Chen</name>
        </author>
        <author>
            <name>H. Shah</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>79</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>LDP</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define the Multipoint LDP (mLDP) model.</p><p> The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-mpls-ldp-yang-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9070</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9071</doc-id>
        <title>RTP-Mixer Formatting of Multiparty Real-Time Text</title>
        <author>
            <name>G. Hellström</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>conference</kw>
            <kw>bridge</kw>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.</p><p> Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP-mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.</p><p> A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".</p><p> This document updates RFC 4103 ("RTP Payload for Text Conversation").</p><p> A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided.</p></abstract>
        <draft>draft-ietf-avtcore-multi-party-rtt-mix-20</draft>
        <updates>
            <doc-id>RFC4103</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9071</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9072</doc-id>
        <title>Extended Optional Parameters Length for BGP OPEN Message</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IDR</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concerns about this limitation.</p><p> This document updates RFC 4271 by extending, in a backward-compatible manner, the length of the Optional Parameters in a BGP OPEN message. The Parameter Length field of individual Optional Parameters is also extended.</p></abstract>
        <draft>draft-ietf-idr-ext-opt-param-13</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9072</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9073</doc-id>
        <title>Event Publishing Extensions to iCalendar</title>
        <author>
            <name>M. Douglass</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>iCalendar</kw>
            <kw>properties</kw>
        </keywords>
        <abstract><p>This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking.</p><p> This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data.</p></abstract>
        <draft>draft-ietf-calext-eventpub-extensions-19</draft>
        <updates>
            <doc-id>RFC5545</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9073</errata-url>
        <doi>10.17487/RFC9073</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9074</doc-id>
        <title>"VALARM" Extensions for iCalendar</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <author>
            <name>K. Murchison</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>alarms</kw>
            <kw>calendaring</kw>
            <kw>iCalendar</kw>
            <kw>CalDAV</kw>
        </keywords>
        <abstract><p>This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers.</p><p> This document updates RFC 5545.</p></abstract>
        <draft>draft-ietf-calext-valarm-extensions-07</draft>
        <updates>
            <doc-id>RFC5545</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9074</errata-url>
        <doi>10.17487/RFC9074</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9075</doc-id>
        <title>Report from the IAB COVID-19 Network Impacts Workshop 2020</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>The Coronavirus disease (COVID-19) pandemic caused changes in Internet user behavior, particularly during the introduction of initial quarantine and work-from-home arrangements. These behavior changes drove changes in Internet traffic.</p><p> The Internet Architecture Board (IAB) held a workshop to discuss network impacts of the pandemic on November 9-13, 2020. The workshop was held to convene interested researchers, network operators, network management experts, and Internet technologists to share their experiences. The meeting was held online given the ongoing travel and contact restrictions at that time.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-covid19-workshop-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9075</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9076</doc-id>
        <title>DNS Privacy Considerations</title>
        <author>
            <name>T. Wicinski</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document describes the privacy issues associated with the use of the DNS by Internet users.  It provides general observations about typical current privacy practices.  It is intended to be an analysis of the present situation and does not prescribe solutions.  This document obsoletes RFC 7626.</p></abstract>
        <draft>draft-ietf-dprive-rfc7626-bis-09</draft>
        <obsoletes>
            <doc-id>RFC7626</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9076</errata-url>
        <doi>10.17487/RFC9076</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9077</doc-id>
        <title>NSEC and NSEC3: TTLs and Aggressive Use</title>
        <author>
            <name>P. van Dijk</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>negative cache</kw>
            <kw>Denial of Existence</kw>
        </keywords>
        <abstract><p>Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial.  This document changes the definition of the NSEC and NSEC3 TTL to correct that situation.  This document updates RFCs 4034, 4035, 5155, and 8198.</p></abstract>
        <draft>draft-ietf-dnsop-nsec-ttl-05</draft>
        <updates>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC5155</doc-id>
            <doc-id>RFC8198</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9077</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9078</doc-id>
        <title>Reaction: Indicating Summary Reaction to a Message</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>R. Signes</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>reaction</kw>
            <kw>emoji</kw>
            <kw>social networking</kw>
            <kw>email</kw>
            <kw>affect</kw>
            <kw>messaging</kw>
            <kw>emoticon</kw>
            <kw>smileys</kw>
            <kw>like</kw>
            <kw>mime</kw>
            <kw>reply</kw>
        </keywords>
        <abstract><p>The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic.  This specification permits a similar facility for Internet Mail.</p></abstract>
        <draft>draft-crocker-inreply-react-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9078</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9079</doc-id>
        <title>Source-Specific Routing in the Babel Routing Protocol</title>
        <author>
            <name>M. Boutier</name>
        </author>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>SADR</kw>
            <kw>source address-dependent routing</kw>
            <kw>source address</kw>
            <kw>multihoming</kw>
            <kw>multihoming with multiple addresses</kw>
            <kw>multiple addresses</kw>
            <kw>source address selection</kw>
            <kw>multiple routes</kw>
            <kw>multipath</kw>
            <kw>disjoint routes</kw>
            <kw>route diversity</kw>
        </keywords>
        <abstract><p>Source-specific routing, also known as Source Address Dependent Routing (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address.  This document describes an extension for source-specific routing to the Babel routing protocol.</p></abstract>
        <draft>draft-ietf-babel-source-specific-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC9079</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9080</doc-id>
        <title>Homenet Profile of the Babel Routing Protocol</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel.</p></abstract>
        <draft>draft-ietf-homenet-babel-profile-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <doi>10.17487/RFC9080</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9081</doc-id>
        <title>Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>L. Giuliano</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies the procedures for interoperation between Multicast Virtual Private Network (MVPN) Source-Active (SA) routes and customer Multicast Source Discovery Protocol (MSDP) SA routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure.  Without the procedures described in this document, VPN-specific MSDP sessions are required among the Provider Edge (PE) routers that are customer MSDP peers.  This document updates RFC 6514.</p></abstract>
        <draft>draft-ietf-bess-mvpn-msdp-sa-interoperation-08</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9081</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9082</doc-id>
        <title>Registration Data Access Protocol (RDAP) Query Format</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns.  These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).  This document obsoletes RFC 7482.</p></abstract>
        <draft>draft-ietf-regext-rfc7482bis-03</draft>
        <obsoletes>
            <doc-id>RFC7482</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0095</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9082</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9083</doc-id>
        <title>JSON Responses for the Registration Data Access Protocol (RDAP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>June</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>81</page-count>
        <abstract><p>This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs).  These data structures are used to form Registration Data Access Protocol (RDAP) query responses.  This document obsoletes RFC 7483.</p></abstract>
        <draft>draft-ietf-regext-rfc7483bis-05</draft>
        <obsoletes>
            <doc-id>RFC7483</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0095</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9083</errata-url>
        <doi>10.17487/RFC9083</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9084</doc-id>
        <title>OSPF Prefix Originator Extensions</title>
        <author>
            <name>A. Wang</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement.  These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting, and use cases like traffic engineering.</p></abstract>
        <draft>draft-ietf-lsr-ospf-prefix-originator-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9084</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9085</doc-id>
        <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>H. Gredler</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>Segment Routing</kw>
            <kw>SID</kw>
            <kw>MPLS</kw>
            <kw>Label advertisement</kw>
            <kw>IS-IS</kw>
            <kw>OSPF</kw>
            <kw>OSPFv3</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.</p><p> This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.</p></abstract>
        <draft>draft-ietf-idr-bgp-ls-segment-routing-ext-18</draft>
        <updated-by>
            <doc-id>RFC9356</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9085</errata-url>
        <doi>10.17487/RFC9085</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9086</doc-id>
        <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering</title>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>S. Ray</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>BGP-LS</kw>
            <kw>Segment Routing</kw>
        </keywords>
        <abstract><p>A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain.</p><p> This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing.</p></abstract>
        <draft>draft-ietf-idr-bgpls-segment-routing-epe-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9086</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9087</doc-id>
        <title>Segment Routing Centralized BGP Egress Peer Engineering</title>
        <author>
            <name>C. Filsfils</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>G. Dawra</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Aries</name>
        </author>
        <author>
            <name>D. Afanasiev</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.</p><p> The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.</p><p> This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.</p></abstract>
        <draft>draft-ietf-spring-segment-routing-central-epe-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9087</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9088</doc-id>
        <title>Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS</title>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>S. Kini</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL).  An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP.  In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD).  This document defines a mechanism to signal these two capabilities using IS-IS and Border Gateway Protocol - Link State (BGP-LS).</p></abstract>
        <draft>draft-ietf-isis-mpls-elc-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9088</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9089</doc-id>
        <title>Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF</title>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>S. Kini</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL).  An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP.  In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD).  This document defines a mechanism to signal these two capabilities using OSPFv2 and OSPFv3, and Border Gateway Protocol - Link State (BGP-LS).</p></abstract>
        <draft>draft-ietf-ospf-mpls-elc-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9089</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9090</doc-id>
        <title>Concise Binary Object Representation (CBOR) Tags for Object Identifiers</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>ASN.1</kw>
            <kw>OID</kw>
            <kw>Object Identifier</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.</p><p> This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.</p></abstract>
        <draft>draft-ietf-cbor-tags-oid-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC9090</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9091</doc-id>
        <title>Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains</title>
        <author>
            <name>S. Kitterman</name>
        </author>
        <author>
            <name>T. Wicinski</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DMARC</kw>
            <kw>email authentication</kw>
            <kw>TLD</kw>
        </keywords>
        <abstract><p>Domain-based Message Authentication, Reporting, and Conformance (DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling.</p><p> DMARC distinguishes the portion of a name that is a Public Suffix Domain (PSD), below which Organizational Domain names are created. The basic DMARC capability allows Organizational Domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs.</p><p> Some implementations of DMARC consider a PSD to be ineligible for DMARC enforcement. This specification addresses that case.</p></abstract>
        <draft>draft-ietf-dmarc-psd-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dmarc</wg_acronym>
        <doi>10.17487/RFC9091</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9092</doc-id>
        <title>Finding and Using Geofeed Data</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>M. Candela</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.</p></abstract>
        <draft>draft-ietf-opsawg-finding-geofeeds-17</draft>
        <obsoleted-by>
            <doc-id>RFC9632</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9092</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9093</doc-id>
        <title>A YANG Data Model for Layer 0 Types</title>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>A. Guo</name>
        </author>
        <author>
            <name>V. Lopez</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document defines a collection of common data types and groupings in the YANG data modeling language.  These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks.</p></abstract>
        <draft>draft-ietf-ccamp-layer0-types-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC9093</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9094</doc-id>
        <title>A YANG Data Model for Wavelength Switched Optical Networks (WSONs)</title>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>A. Guo</name>
        </author>
        <author>
            <name>V. Lopez</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>56</page-count>
        <abstract><p>This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in Wavelength Switched Optical Networks (WSONs).  The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-ccamp-wson-yang-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9094</errata-url>
        <doi>10.17487/RFC9094</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9095</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration</title>
        <author>
            <name>J. Yao</name>
        </author>
        <author>
            <name>L. Zhou</name>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>N. Kong</name>
        </author>
        <author>
            <name>J. Xie</name>
        </author>
        <date>
            <month>July</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>IDN</kw>
        </keywords>
        <abstract><p>This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names.  Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names.  This is a nonstandard proprietary extension.</p></abstract>
        <draft>draft-yao-regext-bundling-registration-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9095</errata-url>
        <doi>10.17487/RFC9095</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9096</doc-id>
        <title>Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>J. Žorž</name>
        </author>
        <author>
            <name>R. Patterson</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>problem</kw>
            <kw>address</kw>
            <kw>prefix delegation</kw>
            <kw>DHCPv6</kw>
            <kw>stale prefixes</kw>
            <kw>old prefixes</kw>
        </keywords>
        <abstract><p>This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes.  This document updates RFC 7084.</p></abstract>
        <draft>draft-ietf-v6ops-cpe-slaac-renum-08</draft>
        <updates>
            <doc-id>RFC7084</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0234</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC9096</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9097</doc-id>
        <title>Metrics and Methods for One-Way IP Capacity</title>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>R. Geib</name>
        </author>
        <author>
            <name>L. Ciavattone</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IP Layer</kw>
            <kw>Performance</kw>
            <kw>Speed</kw>
            <kw>Access</kw>
        </keywords>
        <abstract><p>This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136.  This memo specifies a more practical Maximum IP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement.</p></abstract>
        <draft>draft-ietf-ippm-capacity-metric-method-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9097</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9098</doc-id>
        <title>Operational Implications of IPv6 Packets with Extension Headers</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>N. Hilliard</name>
        </author>
        <author>
            <name>G. Doering</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-ehs-packet-drops-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9098</errata-url>
        <doi>10.17487/RFC9098</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9099</doc-id>
        <title>Operational Security Considerations for IPv6 Networks</title>
        <author>
            <name>É. Vyncke</name>
        </author>
        <author>
            <name>K. Chittimaneni</name>
        </author>
        <author>
            <name>M. Kaeo</name>
        </author>
        <author>
            <name>E. Rey</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>48</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Security</kw>
            <kw>Operational Security</kw>
        </keywords>
        <abstract><p>Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.</p><p> This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.</p></abstract>
        <draft>draft-ietf-opsec-v6-27</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC9099</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9100</doc-id>
        <title>Sensor Measurement Lists (SenML) Features and Versions</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Internet of Things (IoT)</kw>
            <kw>Internet of Things</kw>
            <kw>IOT</kw>
            <kw>data model</kw>
        </keywords>
        <abstract><p>This short document updates RFC 8428, "Sensor Measurement Lists (SenML)", by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers.</p></abstract>
        <draft>draft-ietf-core-senml-versions-05</draft>
        <updates>
            <doc-id>RFC8428</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9100</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9101</doc-id>
        <title>The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)</title>
        <author>
            <name>N. Sakimura</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Assertion</kw>
            <kw>Claim</kw>
            <kw>Security Token</kw>
            <kw>OAuth</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
            <kw>JSON Web Signature</kw>
            <kw>JWS</kw>
            <kw>JSON Web Encryption</kw>
            <kw>JWE</kw>
        </keywords>
        <abstract><p>The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.</p><p> This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.</p></abstract>
        <draft>draft-ietf-oauth-jwsreq-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9101</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9102</doc-id>
        <title>TLS DNSSEC Chain Extension</title>
        <author>
            <name>V. Dukhovni</name>
        </author>
        <author>
            <name>S. Huque</name>
        </author>
        <author>
            <name>W. Toorop</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>M. Shore</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>43</page-count>
        <abstract><p>This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial-of-existence proof that can be validated.</p><p> This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations.</p></abstract>
        <draft>draft-dukhovni-tls-dnssec-chain-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9102</errata-url>
        <doi>10.17487/RFC9102</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9103</doc-id>
        <title>DNS Zone Transfer over TLS</title>
        <author>
            <name>W. Toorop</name>
        </author>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>S. Sahib</name>
        </author>
        <author>
            <name>P. Aras</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>operations</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract><p>DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections.  The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality.  This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT).  Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport.</p></abstract>
        <draft>draft-ietf-dprive-xfr-over-tls-12</draft>
        <updates>
            <doc-id>RFC1995</doc-id>
            <doc-id>RFC5936</doc-id>
            <doc-id>RFC7766</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <doi>10.17487/RFC9103</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9104</doc-id>
        <title>Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)</title>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>Z. Wang</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Inter-Domain Routing</kw>
        </keywords>
        <abstract><p>Administrative groups are link attributes used for traffic engineering.  This document defines an extension to the Border Gateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs).</p></abstract>
        <draft>draft-ietf-idr-eag-distribution-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9104</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9105</doc-id>
        <title>A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)</title>
        <author>
            <name>B. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Zheng</name>
        </author>
        <author>
            <name>M. Wang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Though being a standard module, this module does not endorse the security mechanisms of the TACACS+ protocol (RFC 8907), and TACACS+ be used within a secure deployment.</p><p> The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p></abstract>
        <draft>draft-ietf-opsawg-tacacs-yang-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9105</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9106</doc-id>
        <title>Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications</title>
        <author>
            <name>A. Biryukov</name>
        </author>
        <author>
            <name>D. Dinu</name>
        </author>
        <author>
            <name>D. Khovratovich</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Argon2d</kw>
            <kw>Argon2i</kw>
            <kw>Argon2id</kw>
            <kw>KDF</kw>
            <kw>Cryptocurrency</kw>
            <kw>Time-Space Trade-Off Attacks</kw>
            <kw>Security</kw>
        </keywords>
        <abstract><p>This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications.  We provide an implementer-oriented description with test vectors.  The purpose is to simplify adoption of Argon2 for Internet protocols.  This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-argon2-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9106</errata-url>
        <doi>10.17487/RFC9106</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9107</doc-id>
        <title>BGP Optimal Route Reflection (BGP ORR)</title>
        <author>
            <name>R. Raszuk</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Decraene</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Cassar</name>
        </author>
        <author>
            <name>E. Åman</name>
        </author>
        <author>
            <name>K. Wang</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IDR</kw>
        </keywords>
        <abstract><p>This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing").</p><p> The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP.</p></abstract>
        <draft>draft-ietf-idr-bgp-optimal-route-reflection-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9107</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9108</doc-id>
        <title>YANG Types for DNS Classes and Resource Record Types</title>
        <author>
            <name>L. Lhotka</name>
        </author>
        <author>
            <name>P. Špaček</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IANA registry</kw>
            <kw>DNS Parameters</kw>
        </keywords>
        <abstract><p>This document introduces the YANG module "iana-dns-class-rr-type", which contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs.  These YANG types are intended as the minimum basis for future data modeling work.</p></abstract>
        <draft>draft-ietf-dnsop-iana-class-type-yang-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9108</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9109</doc-id>
        <title>Network Time Protocol Version 4: Port Randomization</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>G. Gont</name>
        </author>
        <author>
            <name>M. Lichvar</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>security</kw>
            <kw>transport protocols</kw>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP) can operate in several modes.  Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port.  However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks.  This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.</p></abstract>
        <draft>draft-ietf-ntp-port-randomization-08</draft>
        <updates>
            <doc-id>RFC5905</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC9109</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9110</doc-id>
        <title>HTTP Semantics</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>194</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>HTTP semantics</kw>
            <kw>HTTP content</kw>
            <kw>HTTP method</kw>
            <kw>HTTP status code</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</p><p> This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</p></abstract>
        <draft>draft-ietf-httpbis-semantics-19</draft>
        <obsoletes>
            <doc-id>RFC2818</doc-id>
            <doc-id>RFC7230</doc-id>
            <doc-id>RFC7231</doc-id>
            <doc-id>RFC7232</doc-id>
            <doc-id>RFC7233</doc-id>
            <doc-id>RFC7235</doc-id>
            <doc-id>RFC7538</doc-id>
            <doc-id>RFC7615</doc-id>
            <doc-id>RFC7694</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3864</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0097</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9110</errata-url>
        <doi>10.17487/RFC9110</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9111</doc-id>
        <title>HTTP Caching</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>HTTP Caching</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</p><p> This document obsoletes RFC 7234.</p></abstract>
        <draft>draft-ietf-httpbis-cache-19</draft>
        <obsoletes>
            <doc-id>RFC7234</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0098</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9111</errata-url>
        <doi>10.17487/RFC9111</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9112</doc-id>
        <title>HTTP/1.1</title>
        <author>
            <name>R. Fielding</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Nottingham</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>Hypertext Transfer Protocol</kw>
            <kw>HTTP</kw>
            <kw>HTTP message format</kw>
        </keywords>
        <abstract><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</p><p> This document obsoletes portions of RFC 7230.</p></abstract>
        <draft>draft-ietf-httpbis-messaging-19</draft>
        <obsoletes>
            <doc-id>RFC7230</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0099</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9112</errata-url>
        <doi>10.17487/RFC9112</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9113</doc-id>
        <title>HTTP/2</title>
        <author>
            <name>M. Thomson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Benfield</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>78</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>SPDY</kw>
            <kw>Web</kw>
        </keywords>
        <abstract><p>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</p><p> This document obsoletes RFCs 7540 and 8740.</p></abstract>
        <draft>draft-ietf-httpbis-http2bis-07</draft>
        <obsoletes>
            <doc-id>RFC7540</doc-id>
            <doc-id>RFC8740</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9113</errata-url>
        <doi>10.17487/RFC9113</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9114</doc-id>
        <title>HTTP/3</title>
        <author>
            <name>M. Bishop</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>57</page-count>
        <keywords>
            <kw>Transport</kw>
            <kw>QUIC</kw>
            <kw>HTTP/2</kw>
            <kw>HPACK</kw>
            <kw>QPACK</kw>
            <kw>Web</kw>
        </keywords>
        <abstract><p>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.</p></abstract>
        <draft>draft-ietf-quic-http-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9114</errata-url>
        <doi>10.17487/RFC9114</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9115</doc-id>
        <title>An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>D. López</name>
        </author>
        <author>
            <name>A. Pastor Perales</name>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>Content Delivery Network</kw>
            <kw>CDN</kw>
        </keywords>
        <abstract><p>This document defines a profile of the Automatic Certificate Management Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain an X.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party.  A primary use case is that of a Content Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name).  The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time.  Importantly, this mechanism does not require any modification to the deployed TLS clients and servers.</p></abstract>
        <draft>draft-ietf-acme-star-delegation-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9115</errata-url>
        <doi>10.17487/RFC9115</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9116</doc-id>
        <title>A File Format to Aid in Security Vulnerability Disclosure</title>
        <author>
            <name>E. Foudil</name>
        </author>
        <author>
            <name>Y. Shafranovich</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking.  As a result, vulnerabilities may be left unreported.  This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.</p></abstract>
        <draft>draft-foudil-securitytxt-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9116</errata-url>
        <doi>10.17487/RFC9116</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9117</doc-id>
        <title>Revised Validation Procedure for BGP Flow Specifications</title>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>J. Alcaide</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>D. Smith</name>
        </author>
        <author>
            <name>P. Mohapatra</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BGP flowspec</kw>
        </keywords>
        <abstract><p>This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border Gateway Protocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an External Border Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server.</p><p> This document updates the validation procedure in RFC 8955.</p></abstract>
        <draft>draft-ietf-idr-bgp-flowspec-oid-15</draft>
        <updates>
            <doc-id>RFC8955</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9117</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9118</doc-id>
        <title>Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>X.509 Certificate Extension</kw>
        </keywords>
        <abstract><p>RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; these certificates are often called "Secure Telephone Identity Revisited (STIR) Certificates".  RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225.  If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT.  This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims.  The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT.</p></abstract>
        <draft>draft-ietf-stir-enhance-rfc8226-05</draft>
        <updates>
            <doc-id>RFC8226</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC9118</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9119</doc-id>
        <title>Multicast Considerations over IEEE 802 Wireless Media</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>M. McBride</name>
        </author>
        <author>
            <name>D. Stanley</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>JC. Zúñiga</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>IEEE 802 Wireless Multicast</kw>
            <kw>Broadcast</kw>
            <kw>BUM</kw>
            <kw>wifi</kw>
            <kw>wireless</kw>
        </keywords>
        <abstract><p>Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments.  This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast.  Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network.  Finally, some recommendations are provided about the usage and combination of these features and operational choices.</p></abstract>
        <draft>draft-ietf-mboned-ieee802-mcast-problems-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC9119</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9120</doc-id>
        <title>Nameservers for the Address and Routing Parameter Area ("arpa") Domain</title>
        <author>
            <name>K. Davies</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>root zone</kw>
            <kw>IANA</kw>
            <kw>top-level domain</kw>
            <kw>root nameservers</kw>
            <kw>DNS</kw>
            <kw>ARPA</kw>
        </keywords>
        <abstract><p>This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone.</p></abstract>
        <draft>draft-iab-arpa-authoritative-servers-01</draft>
        <updates>
            <doc-id>RFC3172</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9120</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9121</doc-id>
        <title>Deprecating Infrastructure "int" Domains</title>
        <author>
            <name>K. Davies</name>
        </author>
        <author>
            <name>A. Baber</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and it identifies them for removal from the "int" top-level domain.  Any implementations that involve these domains are now deprecated.  This document also changes the status of RFC 1528 and RFC 1706 to Historic.</p></abstract>
        <draft>draft-davies-int-historic-05</draft>
        <obsoletes>
            <doc-id>RFC1528</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1706</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9121</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9122</doc-id>
        <title>IANA Registry for Sieve Actions</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Sieve</kw>
        </keywords>
        <abstract><p>The Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery.  This document creates a registry for Sieve actions to help developers and Sieve extension writers track interactions between different extensions.</p></abstract>
        <draft>draft-ietf-extra-sieve-action-registry-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9122</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC9123</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC9124</doc-id>
        <title>A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices</title>
        <author>
            <name>B. Moran</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>H. Birkholz</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>computer security</kw>
            <kw>smart objects</kw>
        </keywords>
        <abstract><p>Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.</p><p> One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest.</p></abstract>
        <draft>draft-ietf-suit-information-model-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>suit</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9124</errata-url>
        <doi>10.17487/RFC9124</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9125</doc-id>
        <title>Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <date>
            <month>August</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>SR</kw>
            <kw>GW</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load-balancing, and resiliency reasons. Other sites, such as access networks, also need to be connected across backbone networks through gateways.</p><p> This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow data center gateway routers to advertise routes to the prefixes reachable in the site, including advertising them on behalf of other gateways at the same site. This allows segment routing to be used to identify multiple paths across the Internet or backbone network between different gateways. The paths can be selected for load-balancing, resilience, and quality purposes.</p></abstract>
        <draft>draft-ietf-bess-datacenter-gateway-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9125</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9126</doc-id>
        <title>OAuth 2.0 Pushed Authorization Requests</title>
        <author>
            <name>T. Lodderstedt</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>N. Sakimura</name>
        </author>
        <author>
            <name>D. Tonge</name>
        </author>
        <author>
            <name>F. Skokan</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>security</kw>
            <kw>oauth2</kw>
        </keywords>
        <abstract><p>This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.</p></abstract>
        <draft>draft-ietf-oauth-par-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9126</errata-url>
        <doi>10.17487/RFC9126</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9127</doc-id>
        <title>YANG Data Model for Bidirectional Forwarding Detection (BFD)</title>
        <author>
            <name>R. Rahman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Zheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jethanandani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Pallagatti</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>Liveliness check</kw>
            <kw>BGP</kw>
            <kw>OSPF</kw>
            <kw>IS-IS</kw>
            <kw>TCP-AO</kw>
            <kw>MD5</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).</p><p> The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342).</p></abstract>
        <draft>draft-ietf-bfd-yang-17</draft>
        <updated-by>
            <doc-id>RFC9314</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC9127</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9128</doc-id>
        <title>YANG Data Model for Protocol Independent Multicast (PIM)</title>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>P. McAllister</name>
        </author>
        <author>
            <name>A. Peter</name>
        </author>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <author>
            <name>Y. Liu</name>
        </author>
        <author>
            <name>F. Hu</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>Network Management</kw>
            <kw>PIM</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM).  The model covers the PIM protocol configuration, operational state, and event notifications data.</p></abstract>
        <draft>draft-ietf-pim-yang-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9128</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9129</doc-id>
        <title>YANG Data Model for the OSPF Protocol</title>
        <author>
            <name>D. Yeung</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>I. Chen</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>116</page-count>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage OSPF.  The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.</p></abstract>
        <draft>draft-ietf-ospf-yang-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9129</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9130</doc-id>
        <title>YANG Data Model for the IS-IS Protocol</title>
        <author>
            <name>S. Litkowski</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Yeung</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>L. Lhotka</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>103</page-count>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements.</p></abstract>
        <draft>draft-ietf-isis-yang-isis-cfg-42</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9130</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9131</doc-id>
        <title>Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers</title>
        <author>
            <name>J. Linkova</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>SLAAC</kw>
            <kw>stateless address autoconfiguration</kw>
            <kw>neighbor advertisement</kw>
        </keywords>
        <abstract><p>Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information.  This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a new IPv6 address is assigned to a node.  It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address.  These changes will minimize the delay and packet loss when a node initiates connections to an off-link destination from a new IPv6 address.</p></abstract>
        <draft>draft-ietf-6man-grand-07</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9131</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9132</doc-id>
        <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Shallow</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>107</page-count>
        <keywords>
            <kw>security</kw>
            <kw>mitigation</kw>
            <kw>service delivery</kw>
            <kw>connectivity</kw>
            <kw>anti-DDoS</kw>
            <kw>automation</kw>
            <kw>cooperation</kw>
            <kw>resilience</kw>
            <kw>filtering</kw>
            <kw>security center</kw>
            <kw>mitigator</kw>
            <kw>scrubbing</kw>
            <kw>dynamic service protection</kw>
            <kw>dynamic mitigation</kw>
            <kw>cooperative networking</kw>
            <kw>protective networking</kw>
        </keywords>
        <abstract><p>This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.</p><p> A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.</p><p> This document obsoletes RFC 8782.</p></abstract>
        <draft>draft-ietf-dots-rfc8782-bis-08</draft>
        <obsoletes>
            <doc-id>RFC8782</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9132</errata-url>
        <doi>10.17487/RFC9132</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9133</doc-id>
        <title>Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel</title>
        <author>
            <name>K. Nishizuka</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>T. Nagata</name>
        </author>
        <date>
            <month>September</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Mitigation</kw>
            <kw>Automation</kw>
            <kw>Filtering</kw>
            <kw>Protective Networking</kw>
            <kw>Protected Networks</kw>
            <kw>Security</kw>
            <kw>Anti-DDoS</kw>
            <kw>Reactive</kw>
            <kw>Collaborative Networking</kw>
            <kw>Collaborative Security</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active.</p><p> Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.</p></abstract>
        <draft>draft-ietf-dots-signal-filter-control-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC9133</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9134</doc-id>
        <title>RTP Payload Format for ISO/IEC 21122 (JPEG XS)</title>
        <author>
            <name>T. Bruylants</name>
        </author>
        <author>
            <name>A. Descampe</name>
        </author>
        <author>
            <name>C. Damman</name>
        </author>
        <author>
            <name>T. Richter</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>video</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>joint</kw>
            <kw>photographic</kw>
            <kw>experts</kw>
            <kw>group</kw>
            <kw>real-time</kw>
            <kw>stream</kw>
        </keywords>
        <abstract><p>This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting video encoded with JPEG XS (ISO/IEC 21122).  JPEG XS is a low-latency, lightweight image coding system.  Compared to an uncompressed video use case, it allows higher resolutions and video frame rates while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame.</p></abstract>
        <draft>draft-ietf-payload-rtp-jpegxs-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9134</errata-url>
        <doi>10.17487/RFC9134</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9135</doc-id>
        <title>Integrated Routing and Bridging in Ethernet VPN (EVPN)</title>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>S. Thoria</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>IRB</kw>
            <kw>inter-subnet-forwarding</kw>
            <kw>symmetric</kw>
            <kw>asymmetric</kw>
            <kw>mobility</kw>
        </keywords>
        <abstract><p>Ethernet VPN (EVPN) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual.  However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities of EVPN.  This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.</p></abstract>
        <draft>draft-ietf-bess-evpn-inter-subnet-forwarding-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9135</errata-url>
        <doi>10.17487/RFC9135</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9136</doc-id>
        <title>IP Prefix Advertisement in Ethernet VPN (EVPN)</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>RT5</kw>
            <kw>RT-5</kw>
            <kw>Type-5</kw>
            <kw>Interface-less</kw>
            <kw>Interface-ful</kw>
        </keywords>
        <abstract><p>The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network.  In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols.  This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.</p></abstract>
        <draft>draft-ietf-bess-evpn-prefix-advertisement-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9136</errata-url>
        <doi>10.17487/RFC9136</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9137</doc-id>
        <title>Considerations for Cancellation of IETF Meetings</title>
        <author>
            <name>M. Duke</name>
        </author>
        <date>
            <month>October</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>virtualize</kw>
            <kw>postpone</kw>
            <kw>move</kw>
        </keywords>
        <abstract><p>The IETF ordinarily holds three in-person meetings per year to discuss issues and advance the Internet.  However, various events can make a planned in-person meeting infeasible.  This document provides criteria to aid the IETF Administration LLC (IETF LLC), the Internet Engineering Steering Group (IESG), and the Chair of the Internet Research Task Force (IRTF) in deciding to relocate, virtualize, postpone, or cancel an in-person IETF meeting.</p></abstract>
        <draft>draft-ietf-shmoo-cancel-meeting-06</draft>
        <is-also>
            <doc-id>BCP0226</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>shmoo</wg_acronym>
        <doi>10.17487/RFC9137</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9138</doc-id>
        <title>Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)</title>
        <author>
            <name>J. Hong</name>
        </author>
        <author>
            <name>T. You</name>
        </author>
        <author>
            <name>L. Dong</name>
        </author>
        <author>
            <name>C. Westphal</name>
        </author>
        <author>
            <name>B. Ohlman</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking (ICN).  The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc.  in order to forward the object request.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-nrs-requirements-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9138</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9139</doc-id>
        <title>Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)</title>
        <author>
            <name>C. Gündoğan</name>
        </author>
        <author>
            <name>T. Schmidt</name>
        </author>
        <author>
            <name>M. Wählisch</name>
        </author>
        <author>
            <name>C. Scherb</name>
        </author>
        <author>
            <name>C. Marxer</name>
        </author>
        <author>
            <name>C. Tschudin</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>Content-Centric Networking (CCNx)</kw>
            <kw>Named Data Networking (NDN)</kw>
            <kw>header compression</kw>
            <kw>fragmentation</kw>
            <kw>6LoWPAN</kw>
            <kw>Internet of Things (IoT)</kw>
        </keywords>
        <abstract><p>This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.</p><p> This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-icnlowpan-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9139</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9140</doc-id>
        <title>Nimble Out-of-Band Authentication for EAP (EAP-NOOB)</title>
        <author>
            <name>T. Aura</name>
        </author>
        <author>
            <name>M. Sethi</name>
        </author>
        <author>
            <name>A. Peltonen</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>IoT security</kw>
            <kw>cybersecurity</kw>
            <kw>network access authorization</kw>
            <kw>Extensible Authentication Protocol</kw>
            <kw>key exchange</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods.  This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation.  The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials.  The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange.  The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length.</p></abstract>
        <draft>draft-ietf-emu-eap-noob-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC9140</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9141</doc-id>
        <title>Updating References to the IETF FTP Service</title>
        <author>
            <name>R. Danyliw</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>The IETF FTP service running at ftp.ietf.org, ops.ietf.org, and ietf.org will be retired.  A number of published RFCs in the IETF and IAB streams include URIs that reference this FTP service.  To ensure that the materials referenced using the IETF FTP service can still be found, this document updates the FTP-based references in these affected documents with HTTPS URIs.</p></abstract>
        <draft>draft-danyliw-replace-ftp-pointers-06</draft>
        <updates>
            <doc-id>RFC2077</doc-id>
            <doc-id>RFC2418</doc-id>
            <doc-id>RFC2648</doc-id>
            <doc-id>RFC2954</doc-id>
            <doc-id>RFC2955</doc-id>
            <doc-id>RFC3020</doc-id>
            <doc-id>RFC3083</doc-id>
            <doc-id>RFC3201</doc-id>
            <doc-id>RFC3202</doc-id>
            <doc-id>RFC3295</doc-id>
            <doc-id>RFC3684</doc-id>
            <doc-id>RFC3962</doc-id>
            <doc-id>RFC3970</doc-id>
            <doc-id>RFC4036</doc-id>
            <doc-id>RFC4131</doc-id>
            <doc-id>RFC4251</doc-id>
            <doc-id>RFC4323</doc-id>
            <doc-id>RFC4546</doc-id>
            <doc-id>RFC4547</doc-id>
            <doc-id>RFC4639</doc-id>
            <doc-id>RFC4682</doc-id>
            <doc-id>RFC5098</doc-id>
            <doc-id>RFC5428</doc-id>
            <doc-id>RFC6756</doc-id>
            <doc-id>RFC7241</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9141</errata-url>
        <doi>10.17487/RFC9141</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9142</doc-id>
        <title>Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)</title>
        <author>
            <name>M. Baushke</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>3DES</kw>
            <kw>AES</kw>
            <kw>Advanced Encryption Standard</kw>
            <kw>Curve25519</kw>
            <kw>Curve448</kw>
            <kw>DH</kw>
            <kw>Diffie-Hellman</kw>
            <kw>Digital Encryption Standard</kw>
            <kw>ECC</kw>
            <kw>ECDH</kw>
            <kw>Elliptic Curve Cryptography</kw>
            <kw>Elliptic Curve Diffie-Hellman</kw>
            <kw>FFC</kw>
            <kw>Finite Field Cryptography</kw>
            <kw>IFC</kw>
            <kw>Integer Factorization Cryptography</kw>
            <kw>MODP</kw>
            <kw>MTI</kw>
            <kw>Mandatory to Implement</kw>
            <kw>Modular Exponential</kw>
            <kw>Public Key Exchange</kw>
            <kw>RSA</kw>
            <kw>SHA-2</kw>
            <kw>Secure Shell Key Exchange</kw>
            <kw>Secure Shell</kw>
            <kw>Security Strength</kw>
            <kw>Triple-DES</kw>
            <kw>sha1</kw>
            <kw>sha256</kw>
            <kw>sha384</kw>
            <kw>sha512</kw>
            <kw>SHA-1</kw>
            <kw>Modular Exponentiation</kw>
        </keywords>
        <abstract><p>This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security.  It updates RFCs 4250, 4253, 4432, and 4462.</p></abstract>
        <draft>draft-ietf-curdle-ssh-kex-sha2-20</draft>
        <updates>
            <doc-id>RFC4250</doc-id>
            <doc-id>RFC4253</doc-id>
            <doc-id>RFC4432</doc-id>
            <doc-id>RFC4462</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>curdle</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9142</errata-url>
        <doi>10.17487/RFC9142</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9143</doc-id>
        <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
        <author>
            <name>C. Holmberg</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>SDP</kw>
            <kw>Bundle</kw>
            <kw>Multiplexing</kw>
            <kw>RTCWEB</kw>
            <kw>CLUE</kw>
            <kw>RTCWEB</kw>
            <kw>MMUSIC</kw>
            <kw>AVT</kw>
            <kw>WEB</kw>
            <kw>Browser</kw>
        </keywords>
        <abstract><p>This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.</p><p> This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension.</p><p> This specification updates RFCs 3264, 5888, and 7941.</p><p> This specification obsoletes RFC 8843.</p></abstract>
        <draft>draft-ietf-mmusic-rfc8843bis-09</draft>
        <obsoletes>
            <doc-id>RFC8843</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3264</doc-id>
            <doc-id>RFC5888</doc-id>
            <doc-id>RFC7941</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mmusic</wg_acronym>
        <doi>10.17487/RFC9143</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9144</doc-id>
        <title>Comparison of Network Management Datastore Architecture (NMDA) Datastores</title>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Troubleshooting</kw>
            <kw>YANG RPC</kw>
            <kw>YANG Data Model</kw>
        </keywords>
        <abstract><p>This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-netmod-nmda-diff-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC9144</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9145</doc-id>
        <title>Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Resilience</kw>
            <kw>Automation</kw>
            <kw>Service delivery</kw>
            <kw>Providers</kw>
            <kw>Differentiated services</kw>
            <kw>Traffic Engineering</kw>
            <kw>Attack mitigation</kw>
        </keywords>
        <abstract><p>This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC).  Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH.</p></abstract>
        <draft>draft-ietf-sfc-nsh-integrity-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC9145</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9146</doc-id>
        <title>Connection Identifier for DTLS 1.2</title>
        <author>
            <name>E. Rescorla</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Tschofenig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <author>
            <name>A. Kraus</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>NAT rebinding</kw>
        </keywords>
        <abstract><p>This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2.</p><p> A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context.</p><p> The new ciphertext record format with the CID also provides content type encryption and record layer padding.</p><p> This document updates RFC 6347.</p></abstract>
        <draft>draft-ietf-tls-dtls-connection-id-13</draft>
        <updates>
            <doc-id>RFC6347</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC9146</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9147</doc-id>
        <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>N. Modadugu</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>61</page-count>
        <keywords>
            <kw>Communication Security</kw>
        </keywords>
        <abstract><p>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</p><p> The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</p><p> This document obsoletes RFC 6347.</p></abstract>
        <draft>draft-ietf-tls-dtls13-43</draft>
        <obsoletes>
            <doc-id>RFC6347</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9147</errata-url>
        <doi>10.17487/RFC9147</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9148</doc-id>
        <title>EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol</title>
        <author>
            <name>P. van der Stok</name>
        </author>
        <author>
            <name>P. Kampanakis</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>S. Raza</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS.  Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges.  This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</p></abstract>
        <draft>draft-ietf-ace-coap-est-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9148</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9149</doc-id>
        <title>TLS Ticket Requests</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>C.A. Wood</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>TLS</kw>
            <kw>Tickets</kw>
        </keywords>
        <abstract><p>TLS session tickets enable stateless connection resumption for clients without server-side, per-client state.  Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment.  Clients store and use tickets when resuming future connections.  This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections.  This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste while simultaneously priming clients for future connection attempts.</p></abstract>
        <draft>draft-ietf-tls-ticketrequests-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC9149</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9150</doc-id>
        <title>TLS 1.3 Authentication and Integrity-Only Cipher Suites</title>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>J. Visoky</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>HMAC</kw>
            <kw>IoT</kw>
            <kw>constrained devices</kw>
        </keywords>
        <abstract><p>This document defines the use of cipher suites for TLS 1.3 based on Hashed Message Authentication Code (HMAC).  Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality.  Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication.  This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate.  The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity without supporting confidentiality.</p></abstract>
        <draft>draft-camwinget-tls-ts13-macciphersuites-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9150</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9151</doc-id>
        <title>Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3</title>
        <author>
            <name>D. Cooley</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite.</p><p> The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS or DTLS. It is also appropriate for all other US Government systems that process high-value information.</p><p> The profile is made publicly available here for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-cooley-cnsa-dtls-tls-profile-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9151</errata-url>
        <doi>10.17487/RFC9151</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9152</doc-id>
        <title>Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients</title>
        <author>
            <name>M. Jenkins</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>CNSA</kw>
            <kw>NSS</kw>
        </keywords>
        <abstract><p>This document specifies protocol interfaces profiled by the United States National Security Agency (NSA) for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure Object Delivery Protocol (SODP) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include Enrollment over Secure Transport (EST) and its extensions as well as Certificate Management over CMS (CMC).</p><p> This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP 800-59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-turner-sodp-profile-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9152</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9153</doc-id>
        <title>Drone Remote Identification Protocol (DRIP) Requirements and Terminology</title>
        <author>
            <name>S. Card</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Wiethuechter</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>DRIP</kw>
        </keywords>
        <abstract><p>This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group.  These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications).  DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy.</p></abstract>
        <draft>draft-ietf-drip-reqs-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>drip</wg_acronym>
        <doi>10.17487/RFC9153</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9154</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>R. Wilhelm</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>authinfo</kw>
            <kw>random</kw>
            <kw>short-lived</kw>
            <kw>strong</kw>
            <kw>storing</kw>
            <kw>securely</kw>
        </keywords>
        <abstract><p>The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars".  Object-specific, password-based authorization information (see RFCs 5731 and 5733) is commonly used but raises issues related to the security, complexity, storage, and lifetime of authentication information.  This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash that provides for secure authorization information that can safely be used for object transfers.</p></abstract>
        <draft>draft-ietf-regext-secure-authinfo-transfer-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9154</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9155</doc-id>
        <title>Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2</title>
        <author>
            <name>L. Velvindron</name>
        </author>
        <author>
            <name>K. Moriarty</name>
        </author>
        <author>
            <name>A. Ghedini</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>tls</kw>
        </keywords>
        <abstract><p>The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection.  This document updates RFC 5246.</p></abstract>
        <draft>draft-ietf-tls-md5-sha1-deprecate-09</draft>
        <updates>
            <doc-id>RFC5246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC9155</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9156</doc-id>
        <title>DNS Query Name Minimisation to Improve Privacy</title>
        <author>
            <name>S. Bortzmeyer</name>
        </author>
        <author>
            <name>R. Dolmans</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>QNAME</kw>
        </keywords>
        <abstract><p>This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server.  This document obsoletes RFC 7816.</p></abstract>
        <draft>draft-ietf-dnsop-rfc7816bis-11</draft>
        <obsoletes>
            <doc-id>RFC7816</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9156</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9157</doc-id>
        <title>Revised IANA Considerations for DNSSEC</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries.  It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence).  It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track.  The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-iana-cons-05</draft>
        <updates>
            <doc-id>RFC5155</doc-id>
            <doc-id>RFC6014</doc-id>
            <doc-id>RFC8624</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9157</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9158</doc-id>
        <title>Update to the Object Identifier Registry for the PKIX Working Group</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>November</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>Certificate Request Message Format</kw>
            <kw>CRMF</kw>
            <kw>CRMF Registration Controls</kw>
            <kw>Alternate Certificate Formats</kw>
        </keywords>
        <abstract><p>RFC 7299 describes the object identifiers that were assigned by the Public Key Infrastructure using X.509 (PKIX) Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7).  A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight.</p></abstract>
        <draft>draft-ietf-lamps-rfc7299-update-02</draft>
        <updates>
            <doc-id>RFC7299</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9158</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9159</doc-id>
        <title>IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)</title>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>S.M. Darroudi</name>
        </author>
        <author>
            <name>T. Savolainen</name>
        </author>
        <author>
            <name>M. Spoerk</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Bluetooth Low Energy</kw>
            <kw>mesh networks</kw>
            <kw>6lowpan</kw>
            <kw>IPv6</kw>
            <kw>Low power</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology.  However, recent Bluetooth specifications allow the formation of extended topologies as well.  This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile (IPSP).  This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.</p></abstract>
        <draft>draft-ietf-6lo-blemesh-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC9159</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9160</doc-id>
        <title>Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)</title>
        <author>
            <name>T. Graf</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>control plane migration</kw>
            <kw>traffic monitoring</kw>
            <kw>traffic accounting</kw>
            <kw>OSPF</kw>
            <kw>IS-IS</kw>
            <kw>BGP Prefix-SID</kw>
            <kw>PCE</kw>
            <kw>PCEP SR</kw>
        </keywords>
        <abstract><p>This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol is used within a Segment Routing domain.  In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for Path Computation Element (PCE), IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions.</p></abstract>
        <draft>draft-ietf-opsawg-ipfix-mpls-sr-label-type-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9160</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9161</doc-id>
        <title>Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <author>
            <name>K. Nagaraj</name>
        </author>
        <author>
            <name>G. Hankins</name>
        </author>
        <author>
            <name>T. King</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes the Ethernet Virtual Private Network (EVPN) Proxy ARP/ND function augmented by the capability of the ARP/ND Extended Community.  From that perspective, this document updates the EVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function.  The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of Internet Exchange Points, Data Centers, and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains by reducing and even suppressing the flooding produced by address resolution in the EVPN network.</p></abstract>
        <draft>draft-ietf-bess-evpn-proxy-arp-nd-16</draft>
        <updates>
            <doc-id>RFC7432</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9161</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9162</doc-id>
        <title>Certificate Transparency Version 2.0</title>
        <author>
            <name>B. Laurie</name>
        </author>
        <author>
            <name>E. Messeri</name>
        </author>
        <author>
            <name>R. Stradling</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>certificates</kw>
            <kw>pkix</kw>
            <kw>tls</kw>
            <kw>website</kw>
            <kw>webpki</kw>
            <kw>browsers</kw>
        </keywords>
        <abstract><p>This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</p><p> This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.</p><p> Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</p></abstract>
        <draft>draft-ietf-trans-rfc6962-bis-42</draft>
        <obsoletes>
            <doc-id>RFC6962</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>trans</wg_acronym>
        <doi>10.17487/RFC9162</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9163</doc-id>
        <title>Expect-CT Extension for HTTP</title>
        <author>
            <name>E. Stark</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>Certificate Transparency</kw>
            <kw>Expect-CT</kw>
        </keywords>
        <abstract><p>This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts.  Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments.  Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.</p></abstract>
        <draft>draft-ietf-httpbis-expect-ct-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9163</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9164</doc-id>
        <title>Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>interface address</kw>
            <kw>zone identifier</kw>
        </keywords>
        <abstract><p>This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.</p></abstract>
        <draft>draft-ietf-cbor-network-addresses-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC9164</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9165</doc-id>
        <title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>binary format</kw>
            <kw>data interchange format</kw>
            <kw>description language</kw>
            <kw>schema language</kw>
            <kw>tree grammar</kw>
            <kw>ABNF</kw>
            <kw>Augmented BNF</kw>
            <kw>feature indication</kw>
        </keywords>
        <abstract><p>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.</p><p> The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: .plus, .cat, and .det for the construction of constants; .abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and .feature for indicating the use of a non-basic feature in an instance.</p></abstract>
        <draft>draft-ietf-cbor-cddl-control-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC9165</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9166</doc-id>
        <title>A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping</title>
        <author>
            <name>H. Zhao</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>Y. Liu</name>
        </author>
        <author>
            <name>A. Peter</name>
        </author>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>IGMP Snooping</kw>
            <kw>MLD Snooping</kw>
            <kw>multicast</kw>
            <kw>data model</kw>
            <kw>ietf-igmp-mld-snooping</kw>
            <kw>network management</kw>
            <kw>routing</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping devices.  The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-pim-igmp-mld-snooping-yang-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9166</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9167</doc-id>
        <title>Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>T. Sattler</name>
        </author>
        <author>
            <name>R. Carney</name>
        </author>
        <author>
            <name>J. Kolker</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP clients to query EPP servers regarding maintenance events.</p></abstract>
        <draft>draft-ietf-regext-epp-registry-maintenance-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9167</errata-url>
        <doi>10.17487/RFC9167</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9168</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>FlowSpec</kw>
            <kw>Flow Spec</kw>
        </keywords>
        <abstract><p>The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path.</p><p> Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes.</p><p> This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.</p><p> The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation.</p></abstract>
        <draft>draft-ietf-pce-pcep-flowspec-13</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9168</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9169</doc-id>
        <title>New ASN.1 Modules for the Evidence Record Syntax (ERS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>LTANS</kw>
            <kw>long-term archive</kw>
        </keywords>
        <abstract><p>The Evidence Record Syntax (ERS) and the conventions for including these evidence records in the Server-based Certificate Validation Protocol (SCVP) are expressed using ASN.1.  This document offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 and employ the conventions adopted in RFCs 5911, 5912, and 6268.  There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax.</p></abstract>
        <draft>draft-housley-ers-asn1-modules-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9169</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9170</doc-id>
        <title>Long-Term Viability of Protocol Extension Mechanisms</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <date>
            <month>December</month>
            <year>2021</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Extensions</kw>
            <kw>versions</kw>
            <kw>grease</kw>
        </keywords>
        <abstract><p>The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change.  This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol.  Examples are given where lack of use caused changes to be more difficult or costly.</p></abstract>
        <draft>draft-iab-use-it-or-lose-it-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9170</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9171</doc-id>
        <title>Bundle Protocol Version 7</title>
        <author>
            <name>S. Burleigh</name>
        </author>
        <author>
            <name>K. Fall</name>
        </author>
        <author>
            <name>E. Birrane, III</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>Delay-tolerant networking</kw>
            <kw>disruption-tolerant networking</kw>
        </keywords>
        <abstract><p>This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.</p></abstract>
        <draft>draft-ietf-dtn-bpbis-31</draft>
        <updated-by>
            <doc-id>RFC9713</doc-id>
            <doc-id>RFC9758</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9171</errata-url>
        <doi>10.17487/RFC9171</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9172</doc-id>
        <title>Bundle Protocol Security (BPSec)</title>
        <author>
            <name>E. Birrane, III</name>
        </author>
        <author>
            <name>K. McKeever</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>security</kw>
            <kw>bundle</kw>
            <kw>integrity</kw>
            <kw>confidentiality</kw>
        </keywords>
        <abstract><p>This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP).</p></abstract>
        <draft>draft-ietf-dtn-bpsec-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9172</errata-url>
        <doi>10.17487/RFC9172</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9173</doc-id>
        <title>Default Security Contexts for Bundle Protocol Security (BPSec)</title>
        <author>
            <name>E. Birrane, III</name>
        </author>
        <author>
            <name>A. White</name>
        </author>
        <author>
            <name>S. Heiner</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>security</kw>
            <kw>bundle</kw>
            <kw>integrity</kw>
            <kw>confidentiality</kw>
        </keywords>
        <abstract><p>This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations.  These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network.</p></abstract>
        <draft>draft-ietf-dtn-bpsec-default-sc-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9173</errata-url>
        <doi>10.17487/RFC9173</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9174</doc-id>
        <title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4</title>
        <author>
            <name>B. Sipos</name>
        </author>
        <author>
            <name>M. Demmer</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>S. Perreault</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>62</page-count>
        <abstract><p>This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN).  This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7).  Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles.  This TCPCL version also includes security and extensibility mechanisms.</p></abstract>
        <draft>draft-ietf-dtn-tcpclv4-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <doi>10.17487/RFC9174</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9175</doc-id>
        <title>Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing</title>
        <author>
            <name>C. Amsüss</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>OSCORE</kw>
            <kw>block-wise</kw>
            <kw>DTLS</kw>
            <kw>freshness</kw>
            <kw>delay</kw>
            <kw>denial-of-service</kw>
            <kw>amplification</kw>
            <kw>Message Body Integrity</kw>
            <kw>Concurrent Block-Wise</kw>
            <kw>Request-Response Binding</kw>
            <kw>Token Reuse</kw>
        </keywords>
        <abstract><p>This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases.  The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request.  This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended).</p></abstract>
        <draft>draft-ietf-core-echo-request-tag-14</draft>
        <updates>
            <doc-id>RFC7252</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9175</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9176</doc-id>
        <title>Constrained RESTful Environments (CoRE) Resource Directory</title>
        <author>
            <name>C. Amsüss</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Shelby</name>
        </author>
        <author>
            <name>M. Koster</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>P. van der Stok</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>CoRE</kw>
            <kw>Web Linking</kw>
            <kw>Resource Discovery</kw>
            <kw>Resource Directory</kw>
        </keywords>
        <abstract><p>In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined.</p></abstract>
        <draft>draft-ietf-core-resource-directory-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9176</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9177</doc-id>
        <title>Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>J. Shallow</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Quick-Block</kw>
            <kw>Robust-Block</kw>
            <kw>R-Block</kw>
            <kw>Tough-Block</kw>
            <kw>Resilient-Block</kw>
            <kw>Fast-Block</kw>
            <kw>Resilience</kw>
            <kw>Filtering</kw>
            <kw>Faster transmission</kw>
            <kw>Large amounts of data</kw>
            <kw>Less packet interchange</kw>
            <kw>Fast recovery</kw>
            <kw>DOTS</kw>
        </keywords>
        <abstract><p>This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.</p><p> These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.</p></abstract>
        <draft>draft-ietf-core-new-block-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9177</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9178</doc-id>
        <title>Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>A. Eriksson</name>
        </author>
        <author>
            <name>A. Keränen</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>cellular networks</kw>
        </keywords>
        <abstract><p>This memo discusses the use of the Constrained Application Protocol (CoAP) in building sensors and other devices that employ cellular networks as a communications medium.  Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.</p></abstract>
        <draft>draft-ietf-lwig-cellular-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC9178</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9179</doc-id>
        <title>A YANG Grouping for Geographic Locations</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>geolocation</kw>
        </keywords>
        <abstract><p>This document defines a generic geographical location YANG grouping.  The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object.</p></abstract>
        <draft>draft-ietf-netmod-geo-location-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC9179</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9180</doc-id>
        <title>Hybrid Public Key Encryption</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>K. Bhargavan</name>
        </author>
        <author>
            <name>B. Lipp</name>
        </author>
        <author>
            <name>C. Wood</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>107</page-count>
        <keywords>
            <kw>public-key encryption</kw>
            <kw>key encapsulation</kw>
            <kw>post-quantum public-key encryption</kw>
        </keywords>
        <abstract><p>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-hpke-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9180</errata-url>
        <doi>10.17487/RFC9180</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9181</doc-id>
        <title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title>
        <author>
            <name>S. Barguil</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>service automation</kw>
            <kw>network automation</kw>
            <kw>service delivery</kw>
            <kw>service provisioning</kw>
            <kw>Slice</kw>
            <kw>network slicing</kw>
            <kw>vitalisation</kw>
            <kw>Automation</kw>
            <kw>Network Models</kw>
        </keywords>
        <abstract><p>This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.</p></abstract>
        <draft>draft-ietf-opsawg-vpn-common-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9181</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9182</doc-id>
        <title>A YANG Network Data Model for Layer 3 VPNs</title>
        <author>
            <name>S. Barguil</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Munoz</name>
        </author>
        <author>
            <name>A. Aguado</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>129</page-count>
        <keywords>
            <kw>l3vpn</kw>
            <kw>Automation</kw>
            <kw>Service Provisioning</kw>
            <kw>Network Automation</kw>
            <kw>Service Orchestration</kw>
            <kw>Service Delivery</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
            <kw>Slices</kw>
            <kw>network slicing</kw>
        </keywords>
        <abstract><p>As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.</p><p> The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.</p></abstract>
        <draft>draft-ietf-opsawg-l3sm-l3nm-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9182</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9183</doc-id>
        <title>Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)</title>
        <author>
            <name>M. Zhang</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <author>
            <name>M. Cullen</name>
        </author>
        <author>
            <name>H. Zhai</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>aggregated</kw>
        </keywords>
        <abstract><p>A major issue in multilevel TRILL is how to manage RBridge nicknames.  In this document, area border RBridges use a single nickname in both Level 1 and Level 2.  RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames.</p></abstract>
        <draft>draft-ietf-trill-multilevel-single-nickname-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9183</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9184</doc-id>
        <title>BGP Extended Community Registries Update</title>
        <author>
            <name>C. Loibl</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and is thus misleading.</p><p> This document updates RFCs 7153 and 8955.</p></abstract>
        <draft>draft-ietf-idr-bgp-ext-com-registry-05</draft>
        <updates>
            <doc-id>RFC7153</doc-id>
            <doc-id>RFC8955</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9184</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9185</doc-id>
        <title>DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange</title>
        <author>
            <name>P. Jones</name>
        </author>
        <author>
            <name>P. Ellenbogen</name>
        </author>
        <author>
            <name>N. Ohlmeier</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>PERC</kw>
            <kw>SRTP</kw>
            <kw>RTP</kw>
            <kw>DTLS</kw>
            <kw>DTLS-SRTP</kw>
            <kw>DTLS tunnel</kw>
            <kw>conferencing</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor.  The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the Media Distributor.</p></abstract>
        <draft>draft-ietf-perc-dtls-tunnel-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>perc</wg_acronym>
        <doi>10.17487/RFC9185</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9186</doc-id>
        <title>Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>X. Ji</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>PIM-SM</kw>
            <kw>BFD</kw>
        </keywords>
        <abstract><p>This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode (PIM-SM).  An extension to the PIM Hello message used to bootstrap a point-to-multipoint BFD session is also defined in this document.</p></abstract>
        <draft>draft-ietf-pim-bfd-p2mp-use-case-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9186</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9187</doc-id>
        <title>Sequence Number Extension for Windowed Protocols</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>January</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Sliding window protocols use finite sequence numbers to determine segment placement and order.  These sequence number spaces wrap around and are reused during the operation of such protocols.  This document describes a way to extend the size of these sequence numbers at the endpoints to avoid the impact of that wrap and reuse without transmitting additional information in the packet header.  The resulting extended sequence numbers can be used at the endpoints in encryption and authentication algorithms to ensure input bit patterns do not repeat over the lifetime of a connection.</p></abstract>
        <draft>draft-touch-sne-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9187</errata-url>
        <doi>10.17487/RFC9187</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9188</doc-id>
        <title>Generic Multi-Access (GMA) Encapsulation Protocol</title>
        <author>
            <name>J. Zhu</name>
        </author>
        <author>
            <name>S. Kanugovi</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL.  It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities.  Such optimization requires additional control information, e.g., a sequence number, in each packet.  This document presents a new lightweight and flexible encapsulation protocol for this need.  The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP.  However, this document is not an Internet Standard and does not represent the consensus opinion of the IETF.  This document will enable other developers to build interoperable implementations in order to experiment with the protocol.</p></abstract>
        <draft>draft-zhu-intarea-gma-14</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9188</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9189</doc-id>
        <title>GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2</title>
        <author>
            <name>S. Smyshlyaev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Belyavsky</name>
        </author>
        <author>
            <name>E. Alekseev</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>GOST</kw>
            <kw>cipher suite</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport Layer Security (TLS) protocol version 1.2 to support the Russian cryptographic standard algorithms (called "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations.</p><p> This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types.</p></abstract>
        <draft>draft-smyshlyaev-tls12-gost-suites-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9189</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9190</doc-id>
        <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3</title>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>M. Sethi</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods.  This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS.  TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS.  This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.</p></abstract>
        <draft>draft-ietf-emu-eap-tls13-21</draft>
        <updates>
            <doc-id>RFC5216</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9190</errata-url>
        <doi>10.17487/RFC9190</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9191</doc-id>
        <title>Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods</title>
        <author>
            <name>M. Sethi</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>EAP-TLS</kw>
            <kw>X.509</kw>
            <kw>EAP</kw>
            <kw>authenticator</kw>
            <kw>Maximum Transmission Unit</kw>
            <kw>(MTU)</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods.  EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication.  Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem.  This document looks at this problem in detail and describes the potential solutions available.</p></abstract>
        <draft>draft-ietf-emu-eaptlscert-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC9191</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9192</doc-id>
        <title>Network Service Header (NSH) Fixed-Length Context Header Allocation</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>I. Yerushalmi</name>
        </author>
        <author>
            <name>D. Melman</name>
        </author>
        <author>
            <name>R. Browne</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>NSH</kw>
            <kw>Context Header</kw>
            <kw>timestamp</kw>
        </keywords>
        <abstract><p>The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length Context Header. The allocation of this Context Header, i.e., its structure and semantics, has not been standardized. This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header that incorporates the packet's timestamp, a sequence number, and a source interface identifier.</p><p> Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability.</p></abstract>
        <draft>draft-mymb-sfc-nsh-allocation-timestamp-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9192</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9193</doc-id>
        <title>Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format</title>
        <author>
            <name>A. Keränen</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Internet of Things (IoT)</kw>
            <kw>Internet of Things</kw>
            <kw>IOT</kw>
            <kw>data model</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binary Data Values.  In order to facilitate processing of binary Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied.</p></abstract>
        <draft>draft-ietf-core-senml-data-ct-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9193</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9194</doc-id>
        <title>A YANG Module for IS-IS Reverse Metric</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol.</p></abstract>
        <draft>draft-ietf-lsr-yang-isis-reverse-metric-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9194</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9195</doc-id>
        <title>A File Format for YANG Instance Data</title>
        <author>
            <name>B. Lengyel</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable.  This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata.</p></abstract>
        <draft>draft-ietf-netmod-yang-instance-file-format-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC9195</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9196</doc-id>
        <title>YANG Modules Describing Capabilities for Systems and Datastore Update Notifications</title>
        <author>
            <name>B. Lengyel</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>NMDA</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
        </keywords>
        <abstract><p>This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities".</p><p> The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format.</p><p> The module "ietf-notification-capabilities" augments "ietf-system-capabilities" to specify capabilities related to "Subscription to YANG Notifications for Datastore Updates" (RFC 8641).</p></abstract>
        <draft>draft-ietf-netconf-notification-capabilities-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9196</errata-url>
        <doi>10.17487/RFC9196</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9197</doc-id>
        <title>Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)</title>
        <author>
            <name>F. Brockners</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bhandari</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Mizrahi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>inband</kw>
            <kw>Telemetry</kw>
            <kw>Tracing</kw>
        </keywords>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network.  This document discusses the data fields and associated data types for IOAM.  IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6.  IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.</p></abstract>
        <draft>draft-ietf-ippm-ioam-data-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9197</errata-url>
        <doi>10.17487/RFC9197</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9198</doc-id>
        <title>Advanced Unidirectional Route Assessment (AURA)</title>
        <author>
            <name>J. Alvarez-Hamelin</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <author>
            <name>J. Fabini</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>R. Geib</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Metrics</kw>
            <kw>IPPM</kw>
            <kw>path</kw>
            <kw>parallel paths</kw>
        </keywords>
        <abstract><p>This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology based on the IP Performance Metrics (IPPM) framework (RFC 2330).  This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies.</p></abstract>
        <draft>draft-ietf-ippm-route-10</draft>
        <updates>
            <doc-id>RFC2330</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9198</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9199</doc-id>
        <title>Considerations for Large Authoritative DNS Server Operators</title>
        <author>
            <name>G. Moura</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>J. Heidemann</name>
        </author>
        <author>
            <name>M. Davids</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Routing</kw>
            <kw>DNS</kw>
            <kw>Anycast</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible considerations or advice to authoritative DNS server operators. Authoritative server operators may wish to follow these considerations to improve their DNS services.</p><p> It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service.</p><p> This document is not an IETF consensus document: it is published for informational purposes.</p></abstract>
        <draft>draft-moura-dnsop-authoritative-recommendations-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9199</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9200</doc-id>
        <title>Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>
        <author>
            <name>L. Seitz</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>E. Wahlstroem</name>
        </author>
        <author>
            <name>S. Erdtman</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>72</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>OAuth 2.0</kw>
            <kw>Access Control</kw>
            <kw>Authorization</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth.  The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices.  Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.</p></abstract>
        <draft>draft-ietf-ace-oauth-authz-46</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9200</errata-url>
        <doi>10.17487/RFC9200</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9201</doc-id>
        <title>Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)</title>
        <author>
            <name>L. Seitz</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>OAuth 2.0</kw>
            <kw>Access Control</kw>
            <kw>Authorization</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE).  These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client.</p></abstract>
        <draft>draft-ietf-ace-oauth-params-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9201</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9202</doc-id>
        <title>Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
        <author>
            <name>S. Gerdes</name>
        </author>
        <author>
            <name>O. Bergmann</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>L. Seitz</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Internet of Thinks (IoT)</kw>
            <kw>Internet of Things</kw>
            <kw>IOT</kw>
            <kw>OAuth</kw>
            <kw>Access Token</kw>
        </keywords>
        <abstract><p>This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization.  The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys.  A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.</p></abstract>
        <draft>draft-ietf-ace-dtls-authorize-18</draft>
        <updated-by>
            <doc-id>RFC9430</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9202</errata-url>
        <doi>10.17487/RFC9202</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9203</doc-id>
        <title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
        <author>
            <name>F. Palombini</name>
        </author>
        <author>
            <name>L. Seitz</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>M. Gunnarsson</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>OAuth 2.0</kw>
            <kw>Access Control</kw>
            <kw>Authorization</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework.  It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</p></abstract>
        <draft>draft-ietf-ace-oscore-profile-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9203</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9204</doc-id>
        <title>QPACK: Field Compression for HTTP/3</title>
        <author>
            <name>C. Krasic</name>
        </author>
        <author>
            <name>M. Bishop</name>
        </author>
        <author>
            <name>A. Frindell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>Transport</kw>
            <kw>QUIC</kw>
            <kw>compression</kw>
            <kw>HTTP/3</kw>
            <kw>HPACK</kw>
            <kw>header</kw>
            <kw>field</kw>
            <kw>trailer</kw>
        </keywords>
        <abstract><p>This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3.  This is a variation of HPACK compression that seeks to reduce head-of-line blocking.</p></abstract>
        <draft>draft-ietf-quic-qpack-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9204</errata-url>
        <doi>10.17487/RFC9204</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9205</doc-id>
        <title>Building Protocols with HTTP</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>HTTP API</kw>
        </keywords>
        <abstract><p>Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.</p><p> This document obsoletes RFC 3205.</p></abstract>
        <draft>draft-ietf-httpbis-bcp56bis-15</draft>
        <obsoletes>
            <doc-id>RFC3205</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0056</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9205</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9206</doc-id>
        <title>Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)</title>
        <author>
            <name>L. Corcoran</name>
        </author>
        <author>
            <name>M. Jenkins</name>
        </author>
        <date>
            <month>February</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>post quantum</kw>
            <kw>quantum resistant</kw>
            <kw>NSA</kw>
        </keywords>
        <abstract><p>The United States Government has published the National Security Agency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications.  This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security (IPsec).  It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ IPsec.  This document is also appropriate for all other US Government systems that process high-value information.  It is made publicly available for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-corcoran-cnsa-ipsec-profile-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9206</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9207</doc-id>
        <title>OAuth 2.0 Authorization Server Issuer Identification</title>
        <author>
            <name>K. Meyer zu Selhausen</name>
        </author>
        <author>
            <name>D. Fett</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>security</kw>
            <kw>oauth2</kw>
        </keywords>
        <abstract><p>This document specifies a new parameter called iss.  This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow.  The iss parameter serves as an effective countermeasure to "mix-up attacks".</p></abstract>
        <draft>draft-ietf-oauth-iss-auth-resp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9207</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9208</doc-id>
        <title>IMAP QUOTA Extension</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.</p><p> This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible.</p></abstract>
        <draft>draft-ietf-extra-quota-10</draft>
        <obsoletes>
            <doc-id>RFC2087</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9208</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9209</doc-id>
        <title>The Proxy-Status HTTP Response Header Field</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>P. Sikora</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>proxy</kw>
            <kw>intermediary</kw>
            <kw>reverse proxy</kw>
        </keywords>
        <abstract><p>This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.</p></abstract>
        <draft>draft-ietf-httpbis-proxy-status-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9209</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9210</doc-id>
        <title>DNS Transport over TCP - Operational Requirements</title>
        <author>
            <name>J. Kristoff</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>This document updates RFCs 1123 and 1536.  This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice.  This operational requirement is aligned with the implementation requirements in RFC 7766.  The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session.  The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld.</p></abstract>
        <draft>draft-ietf-dnsop-dns-tcp-requirements-15</draft>
        <updates>
            <doc-id>RFC1123</doc-id>
            <doc-id>RFC1536</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0235</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9210</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9211</doc-id>
        <title>The Cache-Status HTTP Response Header Field</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>http</kw>
            <kw>cache</kw>
            <kw>debugging</kw>
            <kw>x-cache</kw>
        </keywords>
        <abstract><p>To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner.  This specification defines a standard mechanism to do so that is aligned with HTTP's caching model.</p></abstract>
        <draft>draft-ietf-httpbis-cache-header-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9211</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9212</doc-id>
        <title>Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)</title>
        <author>
            <name>N. Gajcowski</name>
        </author>
        <author>
            <name>M. Jenkins</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>NSS</kw>
            <kw>remote administration</kw>
        </keywords>
        <abstract><p>The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications.  This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol.  It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ Secure Shell (SSH).  This document is also appropriate for all other US Government systems that process high-value information.  It is made publicly available for use by developers and operators of these and any other system deployments.</p></abstract>
        <draft>draft-gajcowski-cnsa-ssh-profile-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9212</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9213</doc-id>
        <title>Targeted HTTP Cache Control</title>
        <author>
            <name>S. Ludin</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>Y. Wu</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>CDN</kw>
            <kw>Content Delivery Network</kw>
            <kw>Caching</kw>
        </keywords>
        <abstract><p>This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches.  It also defines one such header field, the CDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches.</p></abstract>
        <draft>draft-ietf-httpbis-targeted-cache-control-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9213</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9214</doc-id>
        <title>OSPFv3 Code Point for MPLS LSP Ping</title>
        <author>
            <name>N. Nainar</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>M. Aissaoui</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>MPLS</kw>
        </keywords>
        <abstract><p>IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols.</p><p> This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping (DDMAP) TLV when the Interior Gateway Protocol (IGP) is OSPFv3. This document also updates RFC 8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when the Segment ID sub-TLV indicates the use of IPv6.</p></abstract>
        <draft>draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06</draft>
        <updates>
            <doc-id>RFC8287</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9214</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9215</doc-id>
        <title>Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure</title>
        <author>
            <name>D. Baryshkov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Nikolaev</name>
        </author>
        <author>
            <name>A. Chelpanov</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>GOST</kw>
            <kw>PKI</kw>
        </keywords>
        <abstract><p>This document describes encoding formats, identifiers, and parameter formats for the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for use in the Internet X.509 Public Key Infrastructure (PKI).</p><p> This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.</p></abstract>
        <draft>draft-deremin-rfc4491-bis-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9215</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9216</doc-id>
        <title>S/MIME Example Keys and Certificates</title>
        <author>
            <name>D. K. Gillmor</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>pkix</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>S/MIME</kw>
            <kw>smime</kw>
            <kw>email</kw>
            <kw>mail</kw>
            <kw>confidentiality</kw>
            <kw>certificate</kw>
            <kw>pkcs8</kw>
            <kw>pkcs12</kw>
            <kw>x509</kw>
            <kw>"test vector"</kw>
        </keywords>
        <abstract><p>The S/MIME development community benefits from sharing samples of signed or encrypted data.  This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.</p></abstract>
        <draft>draft-ietf-lamps-samples-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9216</errata-url>
        <doi>10.17487/RFC9216</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9217</doc-id>
        <title>Current Open Questions in Path-Aware Networking</title>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.</p><p> This document poses questions in path-aware networking, open as of 2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group (PANRG), and has been published to snapshot current thinking in this space.</p></abstract>
        <draft>draft-irtf-panrg-questions-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9217</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9218</doc-id>
        <title>Extensible Prioritization Scheme for HTTP</title>
        <author>
            <name>K. Oku</name>
        </author>
        <author>
            <name>L. Pardue</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Response priority</kw>
            <kw>Stream multiplexing</kw>
            <kw>Reprioritization</kw>
            <kw>Server scheduling</kw>
        </keywords>
        <abstract><p>This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded.  This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses.  These share a common format structure that is designed to provide future extensibility.</p></abstract>
        <draft>draft-ietf-httpbis-priority-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9218</errata-url>
        <doi>10.17487/RFC9218</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9219</doc-id>
        <title>S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>S/MIME</kw>
        </keywords>
        <abstract><p>This document specifies an extension to "The JSON Meta Application Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status.</p></abstract>
        <draft>draft-ietf-jmap-smime-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9219</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9220</doc-id>
        <title>Bootstrapping WebSockets with HTTP/3</title>
        <author>
            <name>R. Hamilton</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>extended connect</kw>
            <kw>42</kw>
        </keywords>
        <abstract><p>The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified.  This document describes how the mechanism is adapted for HTTP/3.</p></abstract>
        <draft>draft-ietf-httpbis-h3-websockets-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9220</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9221</doc-id>
        <title>An Unreliable Datagram Extension to QUIC</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>E. Kinnear</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.</p></abstract>
        <draft>draft-ietf-quic-datagram-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <doi>10.17487/RFC9221</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9222</doc-id>
        <title>Guidelines for Autonomic Service Agents</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>L. Ciavaglia</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <author>
            <name>P. Peloso</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>GRASP</kw>
            <kw>autonomous</kw>
            <kw>autonomic function</kw>
            <kw>self-management</kw>
        </keywords>
        <abstract><p>This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks.  Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic Control Plane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem.</p></abstract>
        <draft>draft-ietf-anima-asa-guidelines-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <doi>10.17487/RFC9222</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9223</doc-id>
        <title>Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)</title>
        <author>
            <name>W. Zia</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <author>
            <name>L. Chaponniere</name>
        </author>
        <author>
            <name>G. Mandyam</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>Broadcast</kw>
            <kw>FEC</kw>
            <kw>DASH</kw>
            <kw>HLS</kw>
            <kw>FLUTE</kw>
        </keywords>
        <abstract><p>The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications.</p><p> The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicast IP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec.</p><p> This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features).</p><p> This is not an IETF specification and does not have IETF consensus.</p></abstract>
        <draft>draft-zia-route-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9223</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9224</doc-id>
        <title>Finding the Authoritative Registration Data Access Protocol (RDAP) Service</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>whois</kw>
            <kw>bootstrap</kw>
            <kw>domain</kw>
            <kw>IDN</kw>
            <kw>DNS</kw>
            <kw>AS</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.  This document obsoletes RFC 7484.</p></abstract>
        <draft>draft-ietf-regext-rfc7484bis-06</draft>
        <obsoletes>
            <doc-id>RFC7484</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0095</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9224</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9225</doc-id>
        <title>Software Defects Considered Harmful</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>C. Morrow</name>
        </author>
        <author>
            <name>R. van Mook</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>bugs</kw>
        </keywords>
        <abstract><p>This document discourages the practice of introducing software defects in general and in network protocol implementations specifically.  Software defects are one of the largest cost drivers for the networking industry.  This document is intended to clarify the best current practice in this regard.</p></abstract>
        <draft>draft-dont-write-bugs-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9225</errata-url>
        <doi>10.17487/RFC9225</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9226</doc-id>
        <title>Bioctal: Hexadecimal 2.0</title>
        <author>
            <name>M. Breen</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors.  An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being.</p></abstract>
        <draft>draft-breen-bioctal-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9226</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9227</doc-id>
        <title>Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>AEAD</kw>
            <kw>MGM</kw>
        </keywords>
        <abstract><p>This document defines a set of encryption transforms for use in the Encapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security (IPsec) protocol suite. The transforms are based on the GOST R 34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.</p><p> This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.</p></abstract>
        <draft>draft-smyslov-esp-gost-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9227</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9228</doc-id>
        <title>Delivered-To Email Header Field</title>
        <author>
            <name>D. Crocker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>handling</kw>
            <kw>email</kw>
            <kw>mhs</kw>
            <kw>recipient</kw>
            <kw>transport</kw>
            <kw>delivery</kw>
            <kw>mda</kw>
            <kw>mta</kw>
            <kw>relay</kw>
            <kw>header</kw>
        </keywords>
        <abstract><p>The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.</p><p> It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information.</p><p> Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns.</p><p> A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process.</p></abstract>
        <draft>draft-crocker-email-deliveredto-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9228</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9229</doc-id>
        <title>IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>routing</kw>
            <kw>transition</kw>
            <kw>IPv6 transition</kw>
            <kw>double-stack</kw>
            <kw>dual-stack</kw>
            <kw>glorious IPv6-only future</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address.</p></abstract>
        <draft>draft-ietf-babel-v4viav6-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC9229</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9230</doc-id>
        <title>Oblivious DNS over HTTPS</title>
        <author>
            <name>E. Kinnear</name>
        </author>
        <author>
            <name>P. McManus</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>T. Verma</name>
        </author>
        <author>
            <name>C.A. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Privacy</kw>
            <kw>DNS Privacy</kw>
            <kw>DoH</kw>
            <kw>ODoH</kw>
            <kw>HPKE</kw>
        </keywords>
        <abstract><p>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.</p><p> This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.</p></abstract>
        <draft>draft-pauly-dprive-oblivious-doh-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9230</errata-url>
        <doi>10.17487/RFC9230</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9231</doc-id>
        <title>Additional XML Security Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>XMLSEC</kw>
            <kw>XMLDSIG</kw>
            <kw>XMLENC</kw>
            <kw>DigestMethod</kw>
            <kw>SigntureMethod</kw>
            <kw>EncryptionMethod</kw>
            <kw>AgreementMethod</kw>
            <kw>KeyDerivationMethod</kw>
            <kw>KeyInfo</kw>
        </keywords>
        <abstract><p>This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management.  These URIs identify algorithms and types of information.  This document also obsoletes and corrects three errata against RFC 6931.</p></abstract>
        <draft>draft-eastlake-rfc6931bis-xmlsec-uris-27</draft>
        <obsoletes>
            <doc-id>RFC6931</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9231</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9232</doc-id>
        <title>Network Telemetry Framework</title>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>F. Qin</name>
        </author>
        <author>
            <name>P. Martinez-Julia</name>
        </author>
        <author>
            <name>L. Ciavaglia</name>
        </author>
        <author>
            <name>A. Wang</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Telemetry</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management.  It encompasses various techniques for remote data generation, collection, correlation, and consumption.  This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue.  This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives.  The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments.</p></abstract>
        <draft>draft-ietf-opsawg-ntf-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9232</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9233</doc-id>
        <title>Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0</title>
        <author>
            <name>P. Fältström</name>
        </author>
        <date>
            <month>March</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>IDN</kw>
            <kw>IDNA</kw>
            <kw>IDNA2008</kw>
        </keywords>
        <abstract><p>This document describes the changes between Unicode 6.0.0 and Unicode 12.0.0 in the context of the current version of Internationalized Domain Names for Applications 2008 (IDNA2008). Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 12.0.0.</p><p> To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008.</p></abstract>
        <draft>draft-faltstrom-unicode12-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9233</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9234</doc-id>
        <title>Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages</title>
        <author>
            <name>A. Azimov</name>
        </author>
        <author>
            <name>E. Bogomazov</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>K. Sriram</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>Route leak</kw>
            <kw>BGP Role</kw>
        </keywords>
        <abstract><p>Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider.  These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes).  Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship.  This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides.  Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.</p></abstract>
        <draft>draft-ietf-idr-bgp-open-policy-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9234</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9235</doc-id>
        <title>TCP Authentication Option (TCP-AO) Test Vectors</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>J. Kuusisaari</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>authentication</kw>
            <kw>option</kw>
            <kw>test vector</kw>
        </keywords>
        <abstract><p>This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6.  This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC).  Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC- SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96.  The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal.</p></abstract>
        <draft>draft-ietf-tcpm-ao-test-vectors-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9235</errata-url>
        <doi>10.17487/RFC9235</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9236</doc-id>
        <title>Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service</title>
        <author>
            <name>J. Hong</name>
        </author>
        <author>
            <name>T. You</name>
        </author>
        <author>
            <name>V. Kafle</name>
        </author>
        <date>
            <month>April</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Information-Centric Networking</kw>
            <kw>Name Resolution Service</kw>
            <kw>Name to location mapping</kw>
        </keywords>
        <abstract><p>This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN).  It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-nrsarch-considerations-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9236</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9237</doc-id>
        <title>An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
            <kw>Access Control</kw>
        </keywords>
        <abstract><p>Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things.</p><p> This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path.</p></abstract>
        <draft>draft-ietf-ace-aif-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9237</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9238</doc-id>
        <title>Loading Manufacturer Usage Description (MUD) URLs from QR Codes</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>J. Latour</name>
        </author>
        <author>
            <name>H. Habibi Gharakheili</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>RLA</kw>
            <kw>ISOIEC189004</kw>
            <kw>ANSI MH10.8.2</kw>
        </keywords>
        <abstract><p>This informational document details a protocol to load Manufacturer Usage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.</p><p> This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest.</p></abstract>
        <draft>draft-richardson-mud-qrcode-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9238</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9239</doc-id>
        <title>Updates to ECMAScript Media Types</title>
        <author>
            <name>M. Miller</name>
        </author>
        <author>
            <name>M. Borins</name>
        </author>
        <author>
            <name>M. Bynens</name>
        </author>
        <author>
            <name>B. Farias</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>JavaScript</kw>
            <kw>ECMAScript</kw>
            <kw>MIME type</kw>
            <kw>Content-Type</kw>
            <kw>modules</kw>
            <kw>TC39</kw>
            <kw>ESM</kw>
        </keywords>
        <abstract><p>This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.  This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences.</p></abstract>
        <draft>draft-ietf-dispatch-javascript-mjs-17</draft>
        <obsoletes>
            <doc-id>RFC4329</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>dispatch</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9239</errata-url>
        <doi>10.17487/RFC9239</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9240</doc-id>
        <title>An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps</title>
        <author>
            <name>W. Roome</name>
        </author>
        <author>
            <name>S. Randriamasy</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>K. Gao</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>53</page-count>
        <keywords>
            <kw>ALTO</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects.  Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol.  While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTO Protocol is extended in two major directions.  First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps.  These extensions introduce additional features that allow entities and property values to be specific to a given information resource.  This is made possible by a generic and flexible design of entity and property types.</p></abstract>
        <draft>draft-ietf-alto-unified-props-new-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC9240</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9241</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)</title>
        <author>
            <name>J. Seedorf</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>K. Ma</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>ALTO</kw>
        </keywords>
        <abstract><p>The Content Delivery Networks Interconnection (CDNI) framework in RFC 6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN.  A CDNI Request Routing Footprint &amp; Capabilities Advertisement interface (FCI) is needed to achieve the goals of a CDNI.  RFC 8008 defines the FCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified.  This document defines a new Application-Layer Traffic Optimization (ALTO) service, called "CDNI Advertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008.</p></abstract>
        <draft>draft-ietf-alto-cdni-request-routing-alto-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC9241</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9242</doc-id>
        <title>Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IKE_INTERMEDIATE</kw>
            <kw>Quantum Computer resistant key exchange method</kw>
            <kw>Post-quantum</kw>
        </keywords>
        <abstract><p>This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2).  This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment.  An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment.  The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-intermediate-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9242</errata-url>
        <doi>10.17487/RFC9242</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9243</doc-id>
        <title>A YANG Data Model for DHCPv6 Configuration</title>
        <author>
            <name>I. Farrer</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>92</page-count>
        <keywords>
            <kw>YANG</kw>
            <kw>NETCONF</kw>
            <kw>REST</kw>
            <kw>data model</kw>
            <kw>DHCPv6</kw>
            <kw>IPv6</kw>
            <kw>configuration</kw>
            <kw>management</kw>
            <kw>lease</kw>
            <kw>prefix delegation</kw>
            <kw>address pool</kw>
            <kw>prefix pool</kw>
        </keywords>
        <abstract><p>This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 8415) servers, relays, and clients.</p></abstract>
        <draft>draft-ietf-dhc-dhcpv6-yang-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC9243</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9244</doc-id>
        <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Reddy.K</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Doron</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>J. Shallow</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>108</page-count>
        <keywords>
            <kw>automation</kw>
            <kw>cybersecurity</kw>
            <kw>DDoS</kw>
            <kw>Resilience</kw>
            <kw>Intelligence</kw>
            <kw>Service delivery</kw>
            <kw>Robustness</kw>
            <kw>Collaborative</kw>
        </keywords>
        <abstract><p>This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.</p><p> This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.</p></abstract>
        <draft>draft-ietf-dots-telemetry-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC9244</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9245</doc-id>
        <title>IETF Discussion List Charter</title>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>S. Harris</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.</p><p> This document obsoletes RFC 3005 and updates RFC 3683.</p></abstract>
        <draft>draft-eggert-bcp45bis-08</draft>
        <obsoletes>
            <doc-id>RFC3005</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3683</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0045</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9245</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9246</doc-id>
        <title>URI Signing for Content Delivery Network Interconnection (CDNI)</title>
        <author>
            <name>R. van Brandenburg</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>P. Sorber</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <abstract><p>This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing method as a JSON Web Token (JWT) profile.</p><p> The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single Content Delivery Network (CDN) scenarios.</p></abstract>
        <draft>draft-ietf-cdni-uri-signing-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC9246</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9247</doc-id>
        <title>BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>S. Zhuang</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>BFD</kw>
            <kw>IS-IS</kw>
            <kw>OSPF</kw>
            <kw>OSPFv3</kw>
        </keywords>
        <abstract><p>Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the S-BFD Discriminators.</p><p> This document defines extensions to the BGP - Link State (BGP-LS) address family to carry the S-BFD Discriminators' information via BGP.</p></abstract>
        <draft>draft-ietf-idr-bgp-ls-sbfd-extensions-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9247</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9248</doc-id>
        <title>Interoperability Profile for Relay User Equipment</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>rue</kw>
            <kw>relay user equipment</kw>
        </keywords>
        <abstract><p>Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user.  The CA interprets using sign language on the videophone link and voice on the telephone link.  Often the interpreters may be employed by a company or agency, termed a "provider" in this document.  The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers.  It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work.  This document describes the interface between a videophone and a provider.</p></abstract>
        <draft>draft-ietf-rum-rue-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>rum</wg_acronym>
        <doi>10.17487/RFC9248</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9249</doc-id>
        <title>A YANG Data Model for NTP</title>
        <author>
            <name>N. Wu</name>
        </author>
        <author>
            <name>D. Dhody</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sinha</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Kumar S N</name>
        </author>
        <author>
            <name>Y. Zhao</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>56</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>YANG</kw>
            <kw>NTPv4</kw>
            <kw>NTPv3</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4.  It can also be used to configure and manage version 3.  The data model includes configuration data and state data.</p></abstract>
        <draft>draft-ietf-ntp-yang-data-model-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9249</errata-url>
        <doi>10.17487/RFC9249</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9250</doc-id>
        <title>DNS over Dedicated QUIC Connections</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>S. Dickinson</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>May</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>QUIC</kw>
            <kw>DNS over QUIC</kw>
            <kw>Encrypted DNS</kw>
            <kw>DoQ</kw>
        </keywords>
        <abstract><p>This document describes the use of QUIC to provide transport confidentiality for DNS.  The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP.  DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP.  This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</p></abstract>
        <draft>draft-ietf-dprive-dnsoquic-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9250</errata-url>
        <doi>10.17487/RFC9250</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9251</doc-id>
        <title>Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)</title>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>S. Thoria</name>
        </author>
        <author>
            <name>M. Mishra</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs).</p></abstract>
        <draft>draft-ietf-bess-evpn-igmp-mld-proxy-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9251</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9252</doc-id>
        <title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)</title>
        <author>
            <name>G. Dawra</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>S. Zhuang</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>SRv6</kw>
        </keywords>
        <abstract><p>This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services.  It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</p></abstract>
        <draft>draft-ietf-bess-srv6-services-15</draft>
        <updated-by>
            <doc-id>RFC9819</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9252</errata-url>
        <doi>10.17487/RFC9252</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9253</doc-id>
        <title>Support for iCalendar Relationships</title>
        <author>
            <name>M. Douglass</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>iCalendar</kw>
            <kw>link</kw>
            <kw>related-to</kw>
            <kw>relationships</kw>
        </keywords>
        <abstract><p>This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data.</p></abstract>
        <draft>draft-ietf-calext-ical-relations-11</draft>
        <updates>
            <doc-id>RFC5545</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9253</errata-url>
        <doi>10.17487/RFC9253</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9254</doc-id>
        <title>Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)</title>
        <author>
            <name>M. Veillette</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Petrov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Pelov</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>CBOR</kw>
        </keywords>
        <abstract><p>YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications.</p><p> This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949).</p></abstract>
        <draft>draft-ietf-core-yang-cbor-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9254</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9255</doc-id>
        <title>The 'I' in RPKI Does Not Stand for Identity</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Resource Public Key Infrastructure</kw>
        </keywords>
        <abstract><p>There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the 'holder' of an INR.  This document specifies that RPKI does not associate to the INR holder.</p></abstract>
        <draft>draft-ietf-sidrops-rpki-has-no-identity-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9255</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9256</doc-id>
        <title>Segment Routing Policy Architecture</title>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <author>
            <name>A. Bogdanov</name>
        </author>
        <author>
            <name>P. Mattes</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Segment Routing</kw>
            <kw>SR Policy</kw>
            <kw>SR-MPLS</kw>
            <kw>SRv6</kw>
            <kw>Traffic Engineering</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</p><p> This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</p></abstract>
        <draft>draft-ietf-spring-segment-routing-policy-22</draft>
        <updates>
            <doc-id>RFC8402</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9256</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9257</doc-id>
        <title>Guidance for External Pre-Shared Key (PSK) Usage in TLS</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>J. Hoyland</name>
        </author>
        <author>
            <name>M. Sethi</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.  It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks.  Advice for applications to help meet these assumptions is provided.  This document also discusses PSK use cases and provisioning processes.  Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.</p></abstract>
        <draft>draft-ietf-tls-external-psk-guidance-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9257</errata-url>
        <doi>10.17487/RFC9257</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9258</doc-id>
        <title>Importing External Pre-Shared Keys (PSKs) for TLS 1.3</title>
        <author>
            <name>D. Benjamin</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3.</p></abstract>
        <draft>draft-ietf-tls-external-psk-importer-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC9258</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9259</doc-id>
        <title>Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)</title>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>S. Matsushima</name>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>SRv6</kw>
            <kw>Segment Routing</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network.  The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints.  In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain.</p></abstract>
        <draft>draft-ietf-6man-spring-srv6-oam-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9259</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9260</doc-id>
        <title>Stream Control Transmission Protocol</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Tüxen</name>
        </author>
        <author>
            <name>K. Nielsen</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>133</page-count>
        <keywords>
            <kw>SCTP</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>transport</kw>
            <kw>packet</kw>
            <kw>network</kw>
        </keywords>
        <abstract><p>This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.</p><p> SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.</p><p> SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:</p><p> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.</p></abstract>
        <draft>draft-ietf-tsvwg-rfc4960-bis-19</draft>
        <obsoletes>
            <doc-id>RFC4460</doc-id>
            <doc-id>RFC4960</doc-id>
            <doc-id>RFC6096</doc-id>
            <doc-id>RFC7053</doc-id>
            <doc-id>RFC8540</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9260</errata-url>
        <doi>10.17487/RFC9260</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9261</doc-id>
        <title>Exported Authenticators in TLS</title>
        <author>
            <name>N. Sullivan</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate.  This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer.</p></abstract>
        <draft>draft-ietf-tls-exported-authenticator-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC9261</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9262</doc-id>
        <title>Tree Engineering for Bit Index Explicit Replication (BIER-TE)</title>
        <author>
            <name>T. Eckert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Menth</name>
        </author>
        <author>
            <name>G. Cauchie</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>BIER</kw>
            <kw>BIER-TE</kw>
            <kw>controller</kw>
            <kw>ECMP</kw>
            <kw>forwarding</kw>
            <kw>traffic-engineering</kw>
            <kw>multicast</kw>
            <kw>pseudocode</kw>
            <kw>routing</kw>
            <kw>traffic-steering</kw>
            <kw>tree-steering</kw>
        </keywords>
        <abstract><p>This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER) packets (RFC 8279); it is called "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER.</p><p> BIER-TE introduces a new semantic for "bit positions" (BPs). These BPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded by BIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER "subdomains" (SDs). Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "Interior Gateway Protocol" (IGP).</p></abstract>
        <draft>draft-ietf-bier-te-arch-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <doi>10.17487/RFC9262</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9263</doc-id>
        <title>Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers</title>
        <author>
            <name>Y. Wei</name>
            <title>Editor</title>
        </author>
        <author>
            <name>U. Elzur</name>
        </author>
        <author>
            <name>S. Majee</name>
        </author>
        <author>
            <name>C. Pignataro</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>SFC metadata</kw>
        </keywords>
        <abstract><p>Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context metadata (MD) with each packet.  Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers.  This document specifies several such Context Headers that can be used within a Service Function Path (SFP).</p></abstract>
        <draft>draft-ietf-sfc-nsh-tlv-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC9263</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9264</doc-id>
        <title>Linkset: Media Types and a Link Relation Type for Link Sets</title>
        <author>
            <name>E. Wilde</name>
        </author>
        <author>
            <name>H. Van de Sompel</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Web linking</kw>
            <kw>Typed links</kw>
            <kw>JSON</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract><p>This specification defines two formats and associated media types for representing sets of links as standalone documents.  One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field.  This specification also introduces a link relation type to support the discovery of sets of links.</p></abstract>
        <draft>draft-ietf-httpapi-linkset-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpapi</wg_acronym>
        <doi>10.17487/RFC9264</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9265</doc-id>
        <title>Forward Erasure Correction (FEC) Coding and Congestion Control in Transport</title>
        <author>
            <name>N. Kuhn</name>
        </author>
        <author>
            <name>E. Lochin</name>
        </author>
        <author>
            <name>F. Michel</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>coding</kw>
            <kw>congestion</kw>
        </keywords>
        <abstract><p>Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.</p><p> This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document.</p></abstract>
        <draft>draft-irtf-nwcrg-coding-and-congestion-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9265</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9266</doc-id>
        <title>Channel Bindings for TLS 1.3</title>
        <author>
            <name>S. Whited</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels".  Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2.  This document updates RFCs 5801, 5802, 5929, and 7677.</p></abstract>
        <draft>draft-ietf-kitten-tls-channel-bindings-for-tls13-16</draft>
        <updates>
            <doc-id>RFC5801</doc-id>
            <doc-id>RFC5802</doc-id>
            <doc-id>RFC5929</doc-id>
            <doc-id>RFC7677</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC9266</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9267</doc-id>
        <title>Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing</title>
        <author>
            <name>S. Dashevskyi</name>
        </author>
        <author>
            <name>D. dos Santos</name>
        </author>
        <author>
            <name>J. Wetzels</name>
        </author>
        <author>
            <name>A. Amri</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>vulnerabilities</kw>
            <kw>vulnerability</kw>
        </keywords>
        <abstract><p>This memo describes common vulnerabilities related to Domain Name System (DNS) resource record (RR) processing as seen in several DNS client implementations.  These vulnerabilities may lead to successful Denial-of-Service and Remote Code Execution attacks against the affected software.  Where applicable, violations of RFC 1035 are mentioned.</p></abstract>
        <draft>draft-dashevskyi-dnsrr-antipatterns-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9267</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9268</doc-id>
        <title>IPv6 Minimum Path MTU Hop-by-Hop Option</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>DPLPMTUD</kw>
            <kw>PMTUD</kw>
        </keywords>
        <abstract><p>This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host.  The recorded value can then be communicated back to the source using the return Path MTU field in the Option.</p></abstract>
        <draft>draft-ietf-6man-mtu-option-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9268</errata-url>
        <doi>10.17487/RFC9268</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9269</doc-id>
        <title>Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks</title>
        <author>
            <name>P. Suthar</name>
        </author>
        <author>
            <name>M. Stolic</name>
        </author>
        <author>
            <name>A. Jangam</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Trossen</name>
        </author>
        <author>
            <name>R. Ravindran</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>LTE</kw>
            <kw>ICN</kw>
            <kw>ICN-4G</kw>
            <kw>ICNoIP</kw>
            <kw>IPoICN</kw>
            <kw>HybridICN</kw>
            <kw>Dual Trannsport</kw>
        </keywords>
        <abstract><p>A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery.  In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server.  From a bandwidth and routing perspective, this approach is inefficient.  Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges.  The focus of this document is to list the options for using Information-Centric Networking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation.  The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack.  With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.</p></abstract>
        <draft>draft-irtf-icnrg-icn-lte-4g-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9269</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9270</doc-id>
        <title>GMPLS Signaling Extensions for Shared Mesh Protection</title>
        <author>
            <name>J. He</name>
        </author>
        <author>
            <name>I. Busi</name>
        </author>
        <author>
            <name>J. Ryoo</name>
        </author>
        <author>
            <name>B. Yoon</name>
        </author>
        <author>
            <name>P. Park</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>GMPLS</kw>
            <kw>Shared mesh protection</kw>
        </keywords>
        <abstract><p>ITU-T Recommendation G.808.3 defines the generic aspects of a Shared Mesh Protection (SMP) mechanism, where the difference between SMP and Shared Mesh Restoration (SMR) is also identified. ITU-T Recommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network.</p><p> This document updates RFCs 4872 and 4873 to provide extensions for Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism.</p></abstract>
        <draft>draft-ietf-teas-gmpls-signaling-smp-12</draft>
        <updates>
            <doc-id>RFC4872</doc-id>
            <doc-id>RFC4873</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC9270</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9271</doc-id>
        <title>Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses</title>
        <author>
            <name>R. Price</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>Uninterruptible</kw>
            <kw>Power</kw>
            <kw>Supply</kw>
            <kw>UPS</kw>
            <kw>NUT</kw>
        </keywords>
        <abstract><p>This document describes the command/response protocol currently used in the management of Uninterruptible Power Supply (UPS) units and other power devices often deployed in small offices and in IT installations subject to an erratic public power supply.  The UPS units typically interface to an Attachment Daemon in the system they protect.  This daemon is in turn polled by a Management Daemon that notifies users and system administrators of power supply incidents and automates system shutdown decisions.  The commands and responses described by this document are exchanged between the UPS Attachment Daemon and the Management Daemon.  The practice current when this protocol was first developed risks weak security, and this is addressed in the Security Considerations sections of this document.</p></abstract>
        <draft>draft-rprice-ups-management-protocol-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9271</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9272</doc-id>
        <title>Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>A. Dolganow</name>
        </author>
        <author>
            <name>H. Bidgoli</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>A. Gulko</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies general rules for the interaction between the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path calculation within the Bit Index Explicit Replication (BIER) architecture.  The semantics defined in this document update RFC 8401 and RFC 8444.  This document also updates the "BIER Algorithm" registry established in RFC 8401.</p></abstract>
        <draft>draft-ietf-bier-bar-ipa-13</draft>
        <updates>
            <doc-id>RFC8401</doc-id>
            <doc-id>RFC8444</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <doi>10.17487/RFC9272</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9273</doc-id>
        <title>Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges</title>
        <author>
            <name>K. Matsuzono</name>
        </author>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>C. Westphal</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>ICN</kw>
            <kw>CCNx</kw>
            <kw>NDN</kw>
            <kw>network coding</kw>
            <kw>in-network cache</kw>
        </keywords>
        <abstract><p>This document describes the current research outcomes in Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN.  This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-nwcrg-nwc-ccn-reqs-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9273</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9274</doc-id>
        <title>A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <date>
            <month>July</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Optimization</kw>
            <kw>service performance</kw>
            <kw>cost metric</kw>
            <kw>routing</kw>
            <kw>computation</kw>
            <kw>networks</kw>
            <kw>service-network interaction</kw>
            <kw>network programming</kw>
        </keywords>
        <abstract><p>This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO) Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values.</p><p> This document updates RFC 7285.</p></abstract>
        <draft>draft-ietf-alto-cost-mode-05</draft>
        <updates>
            <doc-id>RFC7285</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC9274</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9275</doc-id>
        <title>An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector</title>
        <author>
            <name>K. Gao</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>S. Randriamasy</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>network visibility</kw>
            <kw>abstract network element</kw>
            <kw>shared bottleneck</kw>
        </keywords>
        <abstract><p>This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol.  It extends the ALTO cost map and ALTO property map services so that an application can decide to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths.  This is useful for applications whose performance is impacted by specific components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths.  This extension introduces a new abstraction called the "Abstract Network Element" (ANE) to represent these components and encodes a network path as a vector of ANEs.  Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints.</p></abstract>
        <draft>draft-ietf-alto-path-vector-25</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC9275</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9276</doc-id>
        <title>Guidance for NSEC3 Parameter Settings</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>V. Dukhovni</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>DNS</kw>
            <kw>NSEC3</kw>
            <kw>NSEC</kw>
            <kw>Denial of Existence</kw>
        </keywords>
        <abstract><p>NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs.  This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience.  This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.</p></abstract>
        <draft>draft-ietf-dnsop-nsec3-guidance-10</draft>
        <updates>
            <doc-id>RFC5155</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0236</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9276</errata-url>
        <doi>10.17487/RFC9276</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9277</doc-id>
        <title>On Stable Storage for Items in Concise Binary Object Representation (CBOR)</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.</p></abstract>
        <draft>draft-ietf-cbor-file-magic-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9277</errata-url>
        <doi>10.17487/RFC9277</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9278</doc-id>
        <title>JWK Thumbprint URI</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>K. Yasuda</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>JSON Web Key</kw>
            <kw>JWK</kw>
            <kw>Thumbprint</kw>
            <kw>URI</kw>
            <kw>URN</kw>
            <kw>OAuth</kw>
        </keywords>
        <abstract><p>This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value.  JWK Thumbprints are defined in RFC 7638.  This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.</p></abstract>
        <draft>draft-ietf-oauth-jwk-thumbprint-uri-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9278</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9279</doc-id>
        <title>Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension</title>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>H. Asaeda</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>This document specifies a generic mechanism to extend IGMPv3 and Multicast Listener Discovery Version 2 (MLDv2) by using a list of TLVs (Type, Length, and Value).</p></abstract>
        <draft>draft-ietf-pim-igmp-mld-extension-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9279</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9280</doc-id>
        <title>RFC Editor Model (Version 3)</title>
        <author>
            <name>P. Saint-Andre</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>editorial</kw>
            <kw>publication</kw>
            <kw>series</kw>
            <kw>streams</kw>
        </keywords>
        <abstract><p>This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.</p><p> This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.</p></abstract>
        <draft>draft-iab-rfcefdp-rfced-model-13</draft>
        <obsoletes>
            <doc-id>RFC8728</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC7841</doc-id>
            <doc-id>RFC8729</doc-id>
            <doc-id>RFC8730</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC9720</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9280</errata-url>
        <doi>10.17487/RFC9280</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9281</doc-id>
        <title>Entities Involved in the IETF Standards Process</title>
        <author>
            <name>R. Salz</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IESG</kw>
            <kw>RFC Editor</kw>
            <kw>IRTF</kw>
            <kw>IETF LLC</kw>
            <kw>ISOC</kw>
            <kw>registries</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process.</p><p> The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028.</p></abstract>
        <draft>draft-rsalz-2028bis-07</draft>
        <obsoletes>
            <doc-id>RFC2028</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0011</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9281</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9282</doc-id>
        <title>Responsibility Change for the RFC Series</title>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>Protocols</kw>
            <kw>copyrights</kw>
            <kw>intellectual</kw>
            <kw>property</kw>
        </keywords>
        <abstract><p>In RFC 9280, responsibility for the RFC Series moved to the RFC Series Working Group and the RFC Series Approval Board.  It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered.  Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted.</p></abstract>
        <draft>draft-rosen-rfcefdp-update-2026-02</draft>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9282</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9283</doc-id>
        <title>IAB Charter Update for RFC Editor Model</title>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280).</p></abstract>
        <draft>draft-carpenter-rfced-iab-charter-09</draft>
        <updates>
            <doc-id>RFC2850</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0039</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9283</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9284</doc-id>
        <title>Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>W. Pan</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document discusses multihoming considerations for DDoS Open Threat Signaling (DOTS).  The goal is to provide some guidance for DOTS clients and client-domain DOTS gateways when multihomed.</p></abstract>
        <draft>draft-ietf-dots-multihoming-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC9284</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9285</doc-id>
        <title>The Base45 Data Encoding</title>
        <author>
            <name>P. Fältström</name>
        </author>
        <author>
            <name>F. Ljunggren</name>
        </author>
        <author>
            <name>D.W. van Gulik</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BASE45</kw>
        </keywords>
        <abstract><p>This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.</p></abstract>
        <draft>draft-faltstrom-base45-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9285</errata-url>
        <doi>10.17487/RFC9285</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9286</doc-id>
        <title>Manifests for the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>M. Lepinski</name>
        </author>
        <date>
            <month>June</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI).  A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository.  For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content.  Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository.  Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects.  This document obsoletes RFC 6486.</p></abstract>
        <draft>draft-ietf-sidrops-6486bis-11</draft>
        <obsoletes>
            <doc-id>RFC6486</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9286</errata-url>
        <doi>10.17487/RFC9286</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9287</doc-id>
        <title>Greasing the QUIC Bit</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Header</kw>
            <kw>Path signal</kw>
        </keywords>
        <abstract><p>This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets.</p></abstract>
        <draft>draft-ietf-quic-bit-grease-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <doi>10.17487/RFC9287</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9288</doc-id>
        <title>Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>W. Liu</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>Denial of Service</kw>
            <kw>Distributed Denial of Service</kw>
            <kw>DoS</kw>
            <kw>DDoS</kw>
            <kw>ACL</kw>
            <kw>filtering policy</kw>
        </keywords>
        <abstract><p>This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options.  Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain.  Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.</p></abstract>
        <draft>draft-ietf-opsec-ipv6-eh-filtering-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC9288</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9289</doc-id>
        <title>Towards Remote Procedure Call Encryption by Default</title>
        <author>
            <name>T. Myklebust</name>
        </author>
        <author>
            <name>C. Lever</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>network file system</kw>
            <kw>remote procedure call</kw>
            <kw>transport layer security</kw>
            <kw>X.509</kw>
        </keywords>
        <abstract><p>This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in transit.  The proposed mechanism interoperates with Open Network Computing (ONC) RPC implementations that do not support it.  This document updates RFC 5531.</p></abstract>
        <draft>draft-ietf-nfsv4-rpc-tls-11</draft>
        <updates>
            <doc-id>RFC5531</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC9289</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9290</doc-id>
        <title>Concise Problem Details for Constrained Application Protocol (CoAP) APIs</title>
        <author>
            <name>T. Fossati</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>API</kw>
            <kw>Problem Details</kw>
            <kw>CBOR Tag</kw>
            <kw>Language Tag</kw>
            <kw>Bidi</kw>
        </keywords>
        <abstract><p>This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments.  The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.</p></abstract>
        <draft>draft-ietf-core-problem-details-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9290</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9291</doc-id>
        <title>A YANG Network Data Model for Layer 2 VPNs</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Barguil</name>
        </author>
        <author>
            <name>L. Munoz</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>139</page-count>
        <keywords>
            <kw>automation</kw>
            <kw>  network model</kw>
            <kw> service provider</kw>
            <kw>service provisionning</kw>
            <kw> network automation</kw>
            <kw>service delivery</kw>
        </keywords>
        <abstract><p>This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.</p><p> Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.</p></abstract>
        <draft>draft-ietf-opsawg-l2nm-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9291</errata-url>
        <doi>10.17487/RFC9291</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9292</doc-id>
        <title>Binary Representation of HTTP Messages</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document defines a binary format for representing HTTP messages.</p></abstract>
        <draft>draft-ietf-httpbis-binary-message-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9292</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9293</doc-id>
        <title>Transmission Control Protocol (TCP)</title>
        <author>
            <name>W. Eddy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>98</page-count>
        <abstract><p>This document specifies the Transmission Control Protocol (TCP).  TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet.  Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion.  This document collects and brings those changes together with the protocol specification from RFC 793.  This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements.  It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state.  The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</p></abstract>
        <draft>draft-ietf-tcpm-rfc793bis-28</draft>
        <obsoletes>
            <doc-id>RFC0793</doc-id>
            <doc-id>RFC0879</doc-id>
            <doc-id>RFC2873</doc-id>
            <doc-id>RFC6093</doc-id>
            <doc-id>RFC6429</doc-id>
            <doc-id>RFC6528</doc-id>
            <doc-id>RFC6691</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1011</doc-id>
            <doc-id>RFC1122</doc-id>
            <doc-id>RFC5961</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0007</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9293</errata-url>
        <doi>10.17487/RFC9293</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9294</doc-id>
        <title>Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)</title>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>Segment Routing</kw>
            <kw>IS-IS</kw>
            <kw>OSPF</kw>
            <kw>OSPFv3</kw>
        </keywords>
        <abstract><p>Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR).  This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) to enable the advertisement of these application-specific attributes as a part of the topology information from the network.</p></abstract>
        <draft>draft-ietf-idr-bgp-ls-app-specific-attr-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9294</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9295</doc-id>
        <title>Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers</title>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>S. Josefsson</name>
        </author>
        <author>
            <name>D. McCarney</name>
        </author>
        <author>
            <name>T. Ito</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>PKIX</kw>
            <kw>X.509</kw>
            <kw>keyUsage</kw>
            <kw>Elliptic Curve Cryptography</kw>
        </keywords>
        <abstract><p>This document updates RFC 8410 to clarify existing semantics, and specify missing semantics, for key usage bits when used in certificates that support the Ed25519, Ed448, X25519, and X448 Elliptic Curve Cryptography algorithms.</p></abstract>
        <draft>draft-ietf-lamps-8410-ku-clarifications-02</draft>
        <updates>
            <doc-id>RFC8410</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9295</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9296</doc-id>
        <title>ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples</title>
        <author>
            <name>D. Liu</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>C. Zhang</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>ifType</kw>
            <kw>ifStack</kw>
            <kw>point-to-point</kw>
        </keywords>
        <abstract><p>RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the two circuit types used in the link-state routing protocols, and highlights that it is important to identify the correct circuit type when forming adjacencies, flooding link-state database packets, and monitoring the link state.</p><p> This document provides advice about the ifStack for the P2P interface over a LAN Type to facilitate operational control, maintenance, and statistics.</p></abstract>
        <draft>draft-liu-lsr-p2poverlan-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9296</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9297</doc-id>
        <title>HTTP Datagrams and the Capsule Protocol</title>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>L. Pardue</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>quic</kw>
            <kw>http</kw>
            <kw>datagram</kw>
            <kw>fast</kw>
            <kw>tunnels</kw>
            <kw>turtles all the way down</kw>
            <kw>masque</kw>
            <kw>http-ng</kw>
        </keywords>
        <abstract><p>This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection.</p><p> In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections.</p><p> HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications.</p></abstract>
        <draft>draft-ietf-masque-h3-datagram-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>masque</wg_acronym>
        <doi>10.17487/RFC9297</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9298</doc-id>
        <title>Proxying UDP in HTTP</title>
        <author>
            <name>D. Schinazi</name>
        </author>
        <date>
            <month>August</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>quic</kw>
            <kw>http</kw>
            <kw>datagram</kw>
            <kw>udp</kw>
            <kw>proxy</kw>
            <kw>tunnels</kw>
            <kw>quic in quic</kw>
            <kw>turtles all the way down</kw>
            <kw>masque</kw>
            <kw>http-ng</kw>
        </keywords>
        <abstract><p>This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP.  More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy.</p></abstract>
        <draft>draft-ietf-masque-connect-udp-15</draft>
        <updated-by>
            <doc-id>RFC9484</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>masque</wg_acronym>
        <doi>10.17487/RFC9298</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9299</doc-id>
        <title>An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</title>
        <author>
            <name>A. Cabellos</name>
        </author>
        <author>
            <name>D. Saucez</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>LISP</kw>
            <kw>Architecture</kw>
        </keywords>
        <abstract><p>This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols.  This document is used for introductory purposes; more details can be found in the protocol specifications, RFCs 9300 and 9301.</p></abstract>
        <draft>draft-ietf-lisp-introduction-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9299</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9300</doc-id>
        <title>The Locator/ID Separation Protocol (LISP)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <author>
            <name>A. Cabellos</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>LISP data plane</kw>
        </keywords>
        <abstract><p>This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.</p><p> LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.</p><p> This document obsoletes RFC 6830.</p></abstract>
        <draft>draft-ietf-lisp-rfc6830bis-38</draft>
        <obsoletes>
            <doc-id>RFC6830</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9300</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9301</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Control Plane</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>F. Maino</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>A. Cabellos</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.</p><p> By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.</p><p> This document obsoletes RFCs 6830 and 6833.</p></abstract>
        <draft>draft-ietf-lisp-rfc6833bis-31</draft>
        <obsoletes>
            <doc-id>RFC6830</doc-id>
            <doc-id>RFC6833</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9301</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9302</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Map-Versioning</title>
        <author>
            <name>L. Iannone</name>
        </author>
        <author>
            <name>D. Saucez</name>
        </author>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.</p><p> This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document.</p></abstract>
        <draft>draft-ietf-lisp-6834bis-14</draft>
        <obsoletes>
            <doc-id>RFC6834</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9302</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9303</doc-id>
        <title>Locator/ID Separation Protocol Security (LISP-SEC)</title>
        <author>
            <name>F. Maino</name>
        </author>
        <author>
            <name>V. Ermagan</name>
        </author>
        <author>
            <name>A. Cabellos</name>
        </author>
        <author>
            <name>D. Saucez</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>LISP</kw>
            <kw>deployment</kw>
        </keywords>
        <abstract><p>This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process.  LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.</p></abstract>
        <draft>draft-ietf-lisp-sec-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9303</errata-url>
        <doi>10.17487/RFC9303</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9304</doc-id>
        <title>Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>C. Jacquenet</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Shared Experiment Code</kw>
            <kw>LISP codepoints</kw>
            <kw>Experiment Identifier</kw>
            <kw>Experiment ID</kw>
            <kw>LISP Experimental Registry</kw>
            <kw>LISP Extension</kw>
            <kw>Extending LISP</kw>
            <kw>Exhauted LISP types</kw>
            <kw>LISP IANA</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.</p><p> This document obsoletes RFC 8113.</p></abstract>
        <draft>draft-ietf-lisp-rfc8113bis-03</draft>
        <obsoletes>
            <doc-id>RFC8113</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9304</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9305</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Generic Protocol Extension</title>
        <author>
            <name>F. Maino</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Lemon</name>
        </author>
        <author>
            <name>P. Agarwal</name>
        </author>
        <author>
            <name>D. Lewis</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>security</kw>
            <kw>policy</kw>
        </keywords>
        <abstract><p>This document describes extensions to the Locator/ID Separation Protocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.</p></abstract>
        <draft>draft-ietf-lisp-gpe-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9305</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9306</doc-id>
        <title>Vendor-Specific LISP Canonical Address Format (LCAF)</title>
        <author>
            <name>A. Rodriguez-Natal</name>
        </author>
        <author>
            <name>V. Ermagan</name>
        </author>
        <author>
            <name>A. Smirnov</name>
        </author>
        <author>
            <name>V. Ashtaputre</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>lisp</kw>
            <kw>lcaf</kw>
            <kw>internal</kw>
            <kw>domain</kw>
            <kw>organization</kw>
            <kw>private</kw>
        </keywords>
        <abstract><p>This document describes a new Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF), the Vendor-Specific LCAF.  This LCAF enables organizations to have implementation-specific encodings for LCAF addresses.  This document updates RFC 8060.</p></abstract>
        <draft>draft-ietf-lisp-vendor-lcaf-12</draft>
        <updates>
            <doc-id>RFC8060</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9306</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9307</doc-id>
        <title>Report from the IAB Workshop on Analyzing IETF Data (AID) 2021</title>
        <author>
            <name>N. ten Oever</name>
        </author>
        <author>
            <name>C. Cath</name>
        </author>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>C. S. Perkins</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>data science</kw>
            <kw>data analysis</kw>
        </keywords>
        <abstract><p>The "Show me the numbers: Workshop on Analyzing IETF Data (AID)" workshop was convened by the Internet Architecture Board (IAB) from November 29 to December 2, 2021 and hosted by the IN-SIGHT.it project at the University of Amsterdam; however, it was converted to an online-only event. The workshop was organized into two discussion parts with a hackathon activity in between. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-aid-workshop-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9307</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9308</doc-id>
        <title>Applicability of the QUIC Transport Protocol</title>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>application protocol mapping</kw>
            <kw>deployment</kw>
        </keywords>
        <abstract><p>This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC.  Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols.</p></abstract>
        <draft>draft-ietf-quic-applicability-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <doi>10.17487/RFC9308</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9309</doc-id>
        <title>Robots Exclusion Protocol</title>
        <author>
            <name>M. Koster</name>
        </author>
        <author>
            <name>G. Illyes</name>
        </author>
        <author>
            <name>H. Zeller</name>
        </author>
        <author>
            <name>L. Sassman</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>robot</kw>
            <kw>crawler</kw>
            <kw>robots.txt</kw>
        </keywords>
        <abstract><p>This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers.  Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching.</p></abstract>
        <draft>draft-koster-rep-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9309</errata-url>
        <doi>10.17487/RFC9309</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9310</doc-id>
        <title>X.509 Certificate Extension for 5G Network Function Types</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Digital Certificate</kw>
        </keywords>
        <abstract><p>This document specifies the certificate extension for including Network Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280.</p></abstract>
        <draft>draft-ietf-lamps-5g-nftypes-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9310</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9311</doc-id>
        <title>Running an IETF Hackathon</title>
        <author>
            <name>C. Eckel</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards.  This document provides a set of practices that have been used for running IETF Hackathons.  These practices apply to Hackathons in which both in-person and remote participation are possible, with adaptations for Hackathons that are online only.</p></abstract>
        <draft>draft-ietf-shmoo-hackathon-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>shmoo</wg_acronym>
        <doi>10.17487/RFC9311</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9312</doc-id>
        <title>Manageability of the QUIC Transport Protocol</title>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>B. Trammell</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>network management</kw>
            <kw>wire image</kw>
        </keywords>
        <abstract><p>This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions.</p></abstract>
        <draft>draft-ietf-quic-manageability-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9312</errata-url>
        <doi>10.17487/RFC9312</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9313</doc-id>
        <title>Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)</title>
        <author>
            <name>G. Lencse</name>
        </author>
        <author>
            <name>J. Palet Martinez</name>
        </author>
        <author>
            <name>L. Howard</name>
        </author>
        <author>
            <name>R. Patterson</name>
        </author>
        <author>
            <name>I. Farrer</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Transition Technologies</kw>
            <kw>Comparison</kw>
            <kw>IPv4aaS</kw>
            <kw>IPv6-only</kw>
            <kw>464XLAT</kw>
            <kw>DNS64</kw>
            <kw>Dual Stack Lite</kw>
            <kw>Lightweight 4over6</kw>
            <kw>MAP-E</kw>
            <kw>MAP-T</kw>
        </keywords>
        <abstract><p>Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.</p><p> This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs.</p></abstract>
        <draft>draft-ietf-v6ops-transition-comparison-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC9313</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9314</doc-id>
        <title>YANG Data Model for Bidirectional Forwarding Detection (BFD)</title>
        <author>
            <name>M. Jethanandani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Rahman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Zheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Pallagatti</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>September</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>58</page-count>
        <keywords>
            <kw>Liveliness check</kw>
            <kw>BGP</kw>
            <kw>OSPF</kw>
            <kw>IS-IS</kw>
            <kw>TCP-AO</kw>
            <kw>MD5</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).</p><p> The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). This document updates "YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC 9127).</p></abstract>
        <draft>draft-ietf-bfd-rfc9127-bis-04</draft>
        <updates>
            <doc-id>RFC9127</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC9314</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9315</doc-id>
        <title>Intent-Based Networking - Concepts and Definitions</title>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>L. Ciavaglia</name>
        </author>
        <author>
            <name>L. Z. Granville</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Autonomic networking</kw>
            <kw>Network management</kw>
            <kw>Intent-based management</kw>
            <kw>Intent-based management</kw>
            <kw>Policy-based management</kw>
            <kw>policy</kw>
            <kw>policy-based network management</kw>
            <kw>abstraction</kw>
        </keywords>
        <abstract><p>Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions.</p><p> This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes.</p></abstract>
        <draft>draft-irtf-nmrg-ibn-concepts-definitions-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9315</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9316</doc-id>
        <title>Intent Classification</title>
        <author>
            <name>C. Li</name>
        </author>
        <author>
            <name>O. Havel</name>
        </author>
        <author>
            <name>A. Olariu</name>
        </author>
        <author>
            <name>P. Martinez-Julia</name>
        </author>
        <author>
            <name>J. Nobre</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>intent taxonomy</kw>
            <kw>intent-based network</kw>
            <kw>intent users</kw>
            <kw>intent categories</kw>
            <kw>intent types</kw>
            <kw>network management</kw>
            <kw>network automation</kw>
            <kw>network intent</kw>
            <kw>network service</kw>
            <kw>network orchestration</kw>
            <kw>intent translation</kw>
        </keywords>
        <abstract><p>Intent is an abstract, high-level policy used to operate a network. An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle.</p><p> This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development.</p><p> This document is a product of the IRTF Network Management Research Group (NMRG).</p></abstract>
        <draft>draft-irtf-nmrg-ibn-intent-classification-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9316</errata-url>
        <doi>10.17487/RFC9316</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9317</doc-id>
        <title>Operational Considerations for Streaming Media</title>
        <author>
            <name>J. Holland</name>
        </author>
        <author>
            <name>A. Begen</name>
        </author>
        <author>
            <name>S. Dawkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>DASH</kw>
            <kw>HLS</kw>
            <kw>ABR</kw>
            <kw>adaptive streaming</kw>
            <kw>live streaming</kw>
            <kw>live latency</kw>
            <kw>media transport</kw>
        </keywords>
        <abstract><p>This document provides an overview of operational networking and transport protocol issues that pertain to the quality of experience (QoE) when streaming video and other high-bitrate media over the Internet.</p><p> This document explains the characteristics of streaming media delivery that have surprised network designers or transport experts who lack specific media expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of media delivery issues encountered when streaming media over those existing networks.</p></abstract>
        <draft>draft-ietf-mops-streaming-opcons-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mops</wg_acronym>
        <doi>10.17487/RFC9317</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9318</doc-id>
        <title>IAB Workshop Report: Measuring Network Quality for End-Users</title>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>O. Shapira</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>QoE</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
            <kw>Quality of Experience</kw>
            <kw>Measurement</kw>
            <kw>End User</kw>
        </keywords>
        <abstract><p>The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September 14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-mnqeu-report-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9318</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9319</doc-id>
        <title>The Use of maxLength in the Resource Public Key Infrastructure (RPKI)</title>
        <author>
            <name>Y. Gilad</name>
        </author>
        <author>
            <name>S. Goldberg</name>
        </author>
        <author>
            <name>K. Sriram</name>
        </author>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>B. Maddison</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Secure Internet routing</kw>
            <kw>Resource public key infrastructure</kw>
        </keywords>
        <abstract><p>This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA).  One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases.  The recommendations complement and extend those in RFC 7115.  This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services.  Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.</p></abstract>
        <draft>draft-ietf-sidrops-rpkimaxlen-15</draft>
        <is-also>
            <doc-id>BCP0185</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9319</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9320</doc-id>
        <title>Deterministic Networking (DetNet) Bounded Latency</title>
        <author>
            <name>N. Finn</name>
        </author>
        <author>
            <name>J.-Y. Le Boudec</name>
        </author>
        <author>
            <name>E. Mohammadpour</name>
        </author>
        <author>
            <name>J. Zhang</name>
        </author>
        <author>
            <name>B. Varga</name>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>DetNet</kw>
            <kw>bounded latency</kw>
            <kw>zero congestion loss</kw>
        </keywords>
        <abstract><p>This document presents a timing model for sources, destinations, and Deterministic Networking (DetNet) transit nodes.  Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods.  The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service.</p></abstract>
        <draft>draft-ietf-detnet-bounded-latency-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9320</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9321</doc-id>
        <title>Signature Validation Token</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>October</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic.  The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature.  The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time.  Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates.  The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML, PDF, and JSON documents.</p></abstract>
        <draft>draft-santesson-svt-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9321</errata-url>
        <doi>10.17487/RFC9321</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9322</doc-id>
        <title>In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags</title>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>F. Brockners</name>
        </author>
        <author>
            <name>S. Bhandari</name>
        </author>
        <author>
            <name>B. Gafni</name>
        </author>
        <author>
            <name>M. Spiegel</name>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IOAM</kw>
            <kw>Telemetry</kw>
        </keywords>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network.  This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags.</p></abstract>
        <draft>draft-ietf-ippm-ioam-flags-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9322</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9323</doc-id>
        <title>A Profile for RPKI Signed Checklists (RSCs)</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>T. Harrison</name>
        </author>
        <author>
            <name>B. Maddison</name>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>security</kw>
            <kw>cryptography</kw>
            <kw>X.509</kw>
        </keywords>
        <abstract><p>This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a 'checklist').  The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources.  When validated, an RSC confirms that the respective Internet resource holder produced the RSC.</p></abstract>
        <draft>draft-ietf-sidrops-rpki-rsc-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9323</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9324</doc-id>
        <title>Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>P. Smith</name>
        </author>
        <author>
            <name>M. Tinka</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>bgp</kw>
        </keywords>
        <abstract><p>A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data.  This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.</p></abstract>
        <draft>draft-ietf-sidrops-rov-no-rr-08</draft>
        <updates>
            <doc-id>RFC8481</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9324</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9325</doc-id>
        <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
        <author>
            <name>Y. Sheffer</name>
        </author>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <abstract><p>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</p><p> RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</p></abstract>
        <draft>draft-ietf-uta-rfc7525bis-11</draft>
        <obsoletes>
            <doc-id>RFC7525</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5288</doc-id>
            <doc-id>RFC6066</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0195</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <doi>10.17487/RFC9325</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9326</doc-id>
        <title>In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting</title>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>B. Gafni</name>
        </author>
        <author>
            <name>F. Brockners</name>
        </author>
        <author>
            <name>S. Bhandari</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>IOAM</kw>
            <kw>Telemetry</kw>
        </keywords>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information.  Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network.  This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type".  This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets.  The exporting method and format are outside the scope of this document.</p></abstract>
        <draft>draft-ietf-ippm-ioam-direct-export-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9326</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9327</doc-id>
        <title>Control Messages Protocol for Use with Network Time Protocol Version 4</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>mode 6</kw>
            <kw>mode 7</kw>
        </keywords>
        <abstract><p>This document describes the structure of the control messages that were historically used with the Network Time Protocol (NTP) before the advent of more modern control and management approaches. These control messages have been used to monitor and control the NTP application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated NTP specification documented in RFC 5905.</p><p> The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305.</p></abstract>
        <draft>draft-ietf-ntp-mode-6-cmds-11</draft>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC9327</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9328</doc-id>
        <title>RTP Payload Format for Versatile Video Coding (VVC)</title>
        <author>
            <name>S. Zhao</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>Y. Sanchez</name>
        </author>
        <author>
            <name>Y.-K. Wang</name>
        </author>
        <author>
            <name>M. M Hannuksela</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>54</page-count>
        <keywords>
            <kw>H.266</kw>
            <kw>ISO/IEC 23090-3</kw>
            <kw>MPEG-I Part 3</kw>
            <kw>RTP Payload</kw>
            <kw>Video</kw>
        </keywords>
        <abstract><p>This memo describes an RTP payload format for the Versatile Video Coding (VVC) specification, which was published as both ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3.  VVC was developed by the Joint Video Experts Team (JVET).  The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets.  The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-vvc-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9328</errata-url>
        <doi>10.17487/RFC9328</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9329</doc-id>
        <title>TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>November</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>IKE</kw>
            <kw>IKEv2</kw>
            <kw>IPsec</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.</p><p> TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229.</p></abstract>
        <draft>draft-ietf-ipsecme-rfc8229bis-09</draft>
        <obsoletes>
            <doc-id>RFC8229</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9329</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9330</doc-id>
        <title>Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture</title>
        <author>
            <name>B. Briscoe</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. De Schepper</name>
        </author>
        <author>
            <name>M. Bagnulo</name>
        </author>
        <author>
            <name>G. White</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Queuing Delay</kw>
            <kw>One Way Delay</kw>
            <kw>Round-Trip Time</kw>
            <kw>RTT</kw>
            <kw>Jitter</kw>
            <kw>Congestion Control</kw>
            <kw>Congestion Avoidance</kw>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Quality of Experience</kw>
            <kw>QoE</kw>
            <kw>Active Queue Management</kw>
            <kw>AQM</kw>
            <kw>Explicit Congestion Notification</kw>
            <kw>ECN</kw>
            <kw>Pacing</kw>
            <kw>Burstiness</kw>
        </keywords>
        <abstract><p>This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.</p><p> The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance.</p></abstract>
        <draft>draft-ietf-tsvwg-l4s-arch-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9330</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9331</doc-id>
        <title>The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)</title>
        <author>
            <name>K. De Schepper</name>
        </author>
        <author>
            <name>B. Briscoe</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>Burstiness</kw>
            <kw>Performance</kw>
            <kw>Queuing Delay</kw>
            <kw>One Way Delay</kw>
            <kw>Round-Trip Time</kw>
            <kw>RTT</kw>
            <kw>Jitter</kw>
            <kw>Congestion Control</kw>
            <kw>Congestion Avoidance</kw>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Quality of Experience</kw>
            <kw>QoE</kw>
            <kw>Active Queue Management</kw>
            <kw>AQM</kw>
            <kw>Explicit Congestion Notification</kw>
            <kw>ECN</kw>
            <kw>Pacing</kw>
        </keywords>
        <abstract><p>This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.</p><p> The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-l4s-id-29</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9331</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9332</doc-id>
        <title>Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)</title>
        <author>
            <name>K. De Schepper</name>
        </author>
        <author>
            <name>B. Briscoe</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. White</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>52</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Queuing Delay</kw>
            <kw>One Way Delay</kw>
            <kw>Round-Trip Time</kw>
            <kw>RTT</kw>
            <kw>Jitter</kw>
            <kw>Congestion Control</kw>
            <kw>Congestion Avoidance</kw>
            <kw>Quality of Service</kw>
            <kw>QoS</kw>
            <kw>Quality of Experience</kw>
            <kw>QoE</kw>
            <kw>Active Queue Management</kw>
            <kw>AQM</kw>
            <kw>Explicit Congestion Notification</kw>
            <kw>ECN</kw>
            <kw>Pacing</kw>
            <kw>Burstiness</kw>
        </keywords>
        <abstract><p>This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.</p><p> This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices.</p></abstract>
        <draft>draft-ietf-tsvwg-aqm-dualq-coupled-25</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9332</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9333</doc-id>
        <title>Minimal IP Encapsulating Security Payload (ESP)</title>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>T. Guggemos</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document describes the minimal properties that an IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303. Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation.</p><p> This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description.</p></abstract>
        <draft>draft-ietf-lwig-minimal-esp-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lwig</wg_acronym>
        <doi>10.17487/RFC9333</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9334</doc-id>
        <title>Remote ATtestation procedureS (RATS) Architecture</title>
        <author>
            <name>H. Birkholz</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>N. Smith</name>
        </author>
        <author>
            <name>W. Pan</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>evidence</kw>
            <kw>attestation results</kw>
            <kw>epoch</kw>
            <kw>epoch-id</kw>
            <kw>endorsement</kw>
            <kw>attestating environment</kw>
            <kw>reference value</kw>
            <kw>target environment</kw>
            <kw>layered attestation</kw>
            <kw>appraisal policy</kw>
            <kw>background check model</kw>
            <kw>passport model</kw>
            <kw>freshness</kw>
            <kw>recentness</kw>
        </keywords>
        <abstract><p>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state.  This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims.  It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</p></abstract>
        <draft>draft-ietf-rats-architecture-22</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>rats</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9334</errata-url>
        <doi>10.17487/RFC9334</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9335</doc-id>
        <title>Completely Encrypting RTP Header Extensions and Contributing Sources</title>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>S. Murillo</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>SRTP</kw>
        </keywords>
        <abstract><p>While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations.</p><p> This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment.</p></abstract>
        <draft>draft-ietf-avtcore-cryptex-08</draft>
        <updates>
            <doc-id>RFC3711</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9335</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9336</doc-id>
        <title>X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing</title>
        <author>
            <name>T. Ito</name>
        </author>
        <author>
            <name>T. Okubo</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>KeyPurposeIds</kw>
            <kw>Key Purpose Identifier</kw>
            <kw>Document Signing</kw>
        </keywords>
        <abstract><p>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates.  Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document-Signing application.</p></abstract>
        <draft>draft-ietf-lamps-documentsigning-eku-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9336</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9337</doc-id>
        <title>Generating Password-Based Keys Using the GOST Algorithms</title>
        <author>
            <name>E. Karelina</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>password-based cryptography</kw>
            <kw>derived key</kw>
            <kw>GOST algorithms</kw>
            <kw>pkcs5</kw>
            <kw>gost</kw>
        </keywords>
        <abstract><p>This document specifies how to use "PKCS #5: Password-Based Cryptography Specification Version 2.1" (RFC 8018) to generate a symmetric key from a password in conjunction with the Russian national standard GOST algorithms.</p><p> PKCS #5 applies a Pseudorandom Function (PRF) -- a cryptographic hash, cipher, or Hash-Based Message Authentication Code (HMAC) -- to the input password along with a salt value and repeats the process many times to produce a derived key.</p><p> This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here.</p></abstract>
        <draft>draft-pkcs5-gost-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9337</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9338</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>digital signature</kw>
        </keywords>
        <abstract><p>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR.  This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE.  This document updates RFC 9052.</p></abstract>
        <draft>draft-ietf-cose-countersign-10</draft>
        <updates>
            <doc-id>RFC9052</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0096</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9338</errata-url>
        <doi>10.17487/RFC9338</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9339</doc-id>
        <title>OSPF Reverse Metric</title>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>H. Johnston</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>This document specifies the extensions to OSPF that enable a router to use Link-Local Signaling (LLS) to signal the metric that receiving OSPF neighbor(s) should use for a link to the signaling router.  When used on the link to the signaling router, the signaling of this reverse metric (RM) allows a router to influence the amount of traffic flowing towards itself.  In certain use cases, this enables routers to maintain symmetric metrics on both sides of a link between them.</p></abstract>
        <draft>draft-ietf-lsr-ospf-reverse-metric-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9339</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9340</doc-id>
        <title>Architectural Principles for a Quantum Internet</title>
        <author>
            <name>W. Kozlowski</name>
        </author>
        <author>
            <name>S. Wehner</name>
        </author>
        <author>
            <name>R. Van Meter</name>
        </author>
        <author>
            <name>B. Rijsman</name>
        </author>
        <author>
            <name>A. S. Cacciapuoti</name>
        </author>
        <author>
            <name>M. Caleffi</name>
        </author>
        <author>
            <name>S. Nagayama</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Quantum Internet</kw>
            <kw>Architecture</kw>
            <kw>Repeater</kw>
            <kw>Bell Pair</kw>
            <kw>EPR Pair</kw>
        </keywords>
        <abstract><p>The vision of a quantum internet is to enhance existing Internet technology by enabling quantum communication between any two points on Earth.  To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement.  The first quantum entanglement networks have been realised, but there is no practical proposal for how to organise, utilise, and manage such networks.  In this document, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet.  This is intended for general guidance and general interest.  It is also intended to provide a foundation for discussion between physicists and network specialists.  This document is a product of the Quantum Internet Research Group (QIRG).</p></abstract>
        <draft>draft-irtf-qirg-principles-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9340</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9341</doc-id>
        <title>Alternate-Marking Method</title>
        <author>
            <name>G. Fioccola</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Cociglio</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic.  This technology can be applied in various situations and for different protocols.  According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application.  This document obsoletes RFC 8321.</p></abstract>
        <draft>draft-ietf-ippm-rfc8321bis-03</draft>
        <obsoletes>
            <doc-id>RFC8321</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9341</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9342</doc-id>
        <title>Clustered Alternate-Marking Method</title>
        <author>
            <name>G. Fioccola</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Cociglio</name>
        </author>
        <author>
            <name>A. Sapio</name>
        </author>
        <author>
            <name>R. Sisto</name>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Multipoint</kw>
            <kw>Cluster</kw>
            <kw>Performance</kw>
            <kw>Measurement</kw>
            <kw>Monitoring</kw>
            <kw>Passive</kw>
            <kw>Hybrid</kw>
            <kw>Loss</kw>
            <kw>Delay</kw>
            <kw>Delay Variation</kw>
            <kw>Hashing</kw>
            <kw>Closed-Loop</kw>
        </keywords>
        <abstract><p>This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network.  The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking".  This document obsoletes RFC 8889.</p></abstract>
        <draft>draft-ietf-ippm-rfc8889bis-04</draft>
        <obsoletes>
            <doc-id>RFC8889</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9342</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9343</doc-id>
        <title>IPv6 Application of the Alternate-Marking Method</title>
        <author>
            <name>G. Fioccola</name>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <author>
            <name>M. Cociglio</name>
        </author>
        <author>
            <name>F. Qin</name>
        </author>
        <author>
            <name>R. Pang</name>
        </author>
        <date>
            <month>December</month>
            <year>2022</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Extension</kw>
            <kw>Header</kw>
            <kw>Option</kw>
            <kw>Destination</kw>
            <kw>Hop-By-Hop</kw>
            <kw>Performance</kw>
            <kw>Measurement</kw>
            <kw>Monitoring</kw>
            <kw>Passive</kw>
            <kw>Hybrid</kw>
            <kw>Loss</kw>
            <kw>Delay</kw>
            <kw>Delay Variation</kw>
            <kw>Multipoint</kw>
            <kw>Cluster</kw>
            <kw>Closed-Loop</kw>
        </keywords>
        <abstract><p>This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.</p></abstract>
        <draft>draft-ietf-6man-ipv6-alt-mark-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9343</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9344</doc-id>
        <title>CCNinfo: Discovering Content and Network Information in Content-Centric Networks</title>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>A. Ooka</name>
        </author>
        <author>
            <name>X. Shao</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>ICN</kw>
            <kw>CCNx</kw>
            <kw>NDN</kw>
            <kw>CCNinfo</kw>
        </keywords>
        <abstract><p>This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems.</p><p> This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and the specification may change in the future.</p></abstract>
        <draft>draft-irtf-icnrg-ccninfo-15</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9344</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9345</doc-id>
        <title>Delegated Credentials for TLS and DTLS</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>S. Iyengar</name>
        </author>
        <author>
            <name>N. Sullivan</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>certificate</kw>
            <kw>authentication</kw>
            <kw>TLS 1.3</kw>
            <kw>signature scheme</kw>
        </keywords>
        <abstract><p>The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA).  This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.</p></abstract>
        <draft>draft-ietf-tls-subcerts-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>tls</wg_acronym>
        <doi>10.17487/RFC9345</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9346</doc-id>
        <title>IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering</title>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>D. Xiaodong</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ISIS</kw>
            <kw>Inter-AS</kw>
            <kw>TE</kw>
        </keywords>
        <abstract><p>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.</p><p> No support for flooding information from within one AS to another AS is proposed or defined in this document.</p><p> This document builds on RFC 5316 by adding support for IPv6-only operation.</p><p> This document obsoletes RFC 5316.</p></abstract>
        <draft>draft-ietf-lsr-isis-rfc5316bis-07</draft>
        <obsoletes>
            <doc-id>RFC5316</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9346</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9347</doc-id>
        <title>Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <abstract><p>This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in Encapsulating Security Payload (ESP).  This new payload type can be used for various purposes, such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic.  TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel.  The solution allows for congestion control, as well as nonconstant send-rate usage.</p></abstract>
        <draft>draft-ietf-ipsecme-iptfs-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9347</errata-url>
        <doi>10.17487/RFC9347</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9348</doc-id>
        <title>A YANG Data Model for IP Traffic Flow Security</title>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document describes a YANG module for the management of IP Traffic Flow Security (IP-TFS) additions to Internet Key Exchange Protocol version 2 (IKEv2) and IPsec.</p></abstract>
        <draft>draft-ietf-ipsecme-yang-iptfs-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9348</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9349</doc-id>
        <title>Definitions of Managed Objects for IP Traffic Flow Security</title>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>E. Kinzie</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>MIB</kw>
            <kw>IPsec</kw>
            <kw>IP-TRAFFIC-FLOW-SECURITY-MIB</kw>
        </keywords>
        <abstract><p>This document describes managed objects for the management of IP Traffic Flow Security additions to Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec.  This document provides a read-only version of the objects defined in the YANG module for the same purpose, which is in "A YANG Data Model for IP Traffic Flow Security" (RFC 9348).</p></abstract>
        <draft>draft-ietf-ipsecme-mib-iptfs-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9349</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9350</doc-id>
        <title>IGP Flexible Algorithm</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <author>
            <name>A. Gulko</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <abstract><p>IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links.  Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path.  This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network.  This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.</p></abstract>
        <draft>draft-ietf-lsr-flex-algo-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9350</errata-url>
        <doi>10.17487/RFC9350</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9351</doc-id>
        <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement</title>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>S. Zandi</name>
        </author>
        <author>
            <name>G. Dawra</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>BGP-LS</kw>
            <kw>Segment Routing</kw>
            <kw>IS-IS</kw>
            <kw>OSPF</kw>
            <kw>OSPFv3</kw>
        </keywords>
        <abstract><p>Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition (FAD). This definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding.</p><p> Border Gateway Protocol - Link State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the FAD as a part of the topology information from the network.</p></abstract>
        <draft>draft-ietf-idr-bgp-ls-flex-algo-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9351</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9352</doc-id>
        <title>IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>A. Bashandy</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>Z. Hu</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.</p><p> This document updates RFC 7370 by modifying an existing registry.</p></abstract>
        <draft>draft-ietf-lsr-isis-srv6-extensions-19</draft>
        <updates>
            <doc-id>RFC7370</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9352</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9353</doc-id>
        <title>IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)</title>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Q. Ma</name>
        </author>
        <author>
            <name>D. King</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Path Computation Element</kw>
        </keywords>
        <abstract><p>When a Path Computation Element (PCE) is a Label Switching Router (LSR) or a server participating in the Interior Gateway Protocol (IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery (PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO)) support capability.</p><p> This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFCs 5088 and 5089 to allow advertisement of a Key ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability. This document also updates RFCs 8231 and 8306.</p></abstract>
        <draft>draft-ietf-lsr-pce-discovery-security-support-13</draft>
        <updates>
            <doc-id>RFC5088</doc-id>
            <doc-id>RFC5089</doc-id>
            <doc-id>RFC8231</doc-id>
            <doc-id>RFC8306</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9353</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9354</doc-id>
        <title>Transmission of IPv6 Packets over Power Line Communication (PLC) Networks</title>
        <author>
            <name>J. Hou</name>
        </author>
        <author>
            <name>B. Liu</name>
        </author>
        <author>
            <name>Y-G. Hong</name>
        </author>
        <author>
            <name>X. Tang</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>6lo</kw>
            <kw>6lowpan</kw>
            <kw>6lo-plc</kw>
            <kw>6loplc</kw>
            <kw>plc</kw>
        </keywords>
        <abstract><p>Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity.  The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience.  Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications.  This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2.</p></abstract>
        <draft>draft-ietf-6lo-plc-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC9354</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9355</doc-id>
        <title>OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode</title>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>A. Fu</name>
        </author>
        <author>
            <name>M. Rajesh</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IGP</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>This document specifies the extensions to OSPF that enable an OSPF
router to signal the requirement for a Bidirectional Forwarding
Detection (BFD) session prior to adjacency formation. Link-Local
Signaling (LLS) is used to advertise the requirement for strict-mode
BFD session establishment for an OSPF adjacency. If both OSPF
neighbors advertise BFD strict-mode, adjacency formation will be
blocked until a BFD session has been successfully established.</p><p> This document updates RFC 2328 by augmenting the OSPF neighbor state
machine with a check for BFD session up before progression from Init
to 2-Way state when operating in OSPF BFD strict-mode.</p></abstract>
        <draft>draft-ietf-lsr-ospf-bfd-strict-mode-10</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9355</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9356</doc-id>
        <title>Advertising Layer 2 Bundle Member Link Attributes in OSPF</title>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <date>
            <month>January</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>OSPF</kw>
        </keywords>
        <abstract><p>There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required.</p><p> This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the Border Gateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085.</p></abstract>
        <draft>draft-ietf-lsr-ospf-l2bundles-10</draft>
        <updates>
            <doc-id>RFC9085</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9356</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9357</doc-id>
        <title>Label Switched Path (LSP) Object Flag Extension for Stateful PCE</title>
        <author>
            <name>Q. Xiong</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>PCEP</kw>
        </keywords>
        <abstract><p>RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned.</p><p> This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field.</p></abstract>
        <draft>draft-ietf-pce-lsp-extended-flags-09</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9357</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9358</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks</title>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Association</kw>
            <kw>Association Group</kw>
            <kw>VNAG</kw>
        </keywords>
        <abstract><p>This document describes how to extend the Path Computation Element Communication Protocol (PCEP) association mechanism introduced by RFC 8697 to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application.  This extended association mechanism can be used to facilitate control of a VN using the PCE architecture.</p></abstract>
        <draft>draft-ietf-pce-vn-association-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9358</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9359</doc-id>
        <title>Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities</title>
        <author>
            <name>X. Min</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>L. Bo</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>MPLS</kw>
            <kw>SFC</kw>
            <kw>BIER</kw>
        </keywords>
        <abstract><p>This document describes a generic format for use in echo request/reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node.  The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit Index Explicit Replication (BIER).</p></abstract>
        <draft>draft-ietf-ippm-ioam-conf-state-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9359</errata-url>
        <doi>10.17487/RFC9359</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9360</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general.  For some algorithms, additional properties are defined that carry parameters relating to keys as needed.  The COSE Key structure is used for transporting keys outside of COSE messages.  This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.</p></abstract>
        <draft>draft-ietf-cose-x509-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC9360</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9361</doc-id>
        <title>ICANN Trademark Clearinghouse (TMCH) Functional Specifications</title>
        <author>
            <name>G. Lozano</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>50</page-count>
        <keywords>
            <kw>Trademark Clearinghouse</kw>
            <kw>TMDB</kw>
            <kw>ICANN</kw>
            <kw>TMCH</kw>
            <kw>gTLD</kw>
            <kw>new gTLD</kw>
            <kw>mark</kw>
        </keywords>
        <abstract><p>This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries, as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.</p></abstract>
        <draft>draft-ietf-regext-tmch-func-spec-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9361</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9362</doc-id>
        <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>J. Shallow</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Quick-Block</kw>
            <kw>Robust-Block</kw>
            <kw>R-Block</kw>
            <kw>Tough-Block</kw>
            <kw>Resilient-Block</kw>
            <kw>Fast-Block</kw>
            <kw>Resilience</kw>
            <kw>Filtering</kw>
            <kw>Faster transmission</kw>
            <kw>Large amounts of data</kw>
            <kw>Less packet interchange</kw>
            <kw>Fast recovery</kw>
        </keywords>
        <abstract><p>This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 Constrained Application Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks).</p><p> Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132.</p></abstract>
        <draft>draft-ietf-dots-robust-blocks-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC9362</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9363</doc-id>
        <title>A YANG Data Model for Static Context Header Compression (SCHC)</title>
        <author>
            <name>A. Minaburo</name>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>Header Compression</kw>
            <kw>Fragmentation</kw>
            <kw>SCHC Rule</kw>
            <kw>IPv6</kw>
            <kw>UDP</kw>
            <kw>CoAP</kw>
            <kw>OSCORE</kw>
        </keywords>
        <abstract><p>This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules.</p><p> This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules.</p></abstract>
        <draft>draft-ietf-lpwan-schc-yang-data-model-21</draft>
        <updated-by>
            <doc-id>RFC9441</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC9363</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9364</doc-id>
        <title>DNS Security Extensions (DNSSEC)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>DNS Security Extensions</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others.  One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC.  This document does not update any of those RFCs.  A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice.  A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-bcp-06</draft>
        <is-also>
            <doc-id>BCP0237</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9364</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9365</doc-id>
        <title>IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases</title>
        <author>
            <name>J. Jeong</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS).  The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications.  First, this document explains use cases using V2V, V2I, and V2X networking.  Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy).</p></abstract>
        <draft>draft-ietf-ipwave-vehicular-networking-30</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ipwave</wg_acronym>
        <doi>10.17487/RFC9365</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9366</doc-id>
        <title>Multiple SIP Reason Header Field Values</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <abstract><p>The SIP Reason header field as defined in RFC 3326 allows only one Reason value per protocol value.  Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value.  This document updates RFC 3326 to allow multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means.</p></abstract>
        <draft>draft-ietf-sipcore-multiple-reasons-01</draft>
        <updates>
            <doc-id>RFC3326</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC9366</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9367</doc-id>
        <title>GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3</title>
        <author>
            <name>S. Smyshlyaev</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Alekseev</name>
        </author>
        <author>
            <name>E. Griboedova</name>
        </author>
        <author>
            <name>A. Babueva</name>
        </author>
        <author>
            <name>L. Nikiforova</name>
        </author>
        <date>
            <month>February</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>71</page-count>
        <keywords>
            <kw>GOST</kw>
            <kw>cipher suite</kw>
            <kw>TLS 1.3</kw>
            <kw>signature scheme</kw>
        </keywords>
        <abstract><p>The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3.</p><p> This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, called GOST algorithms, with TLS Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document.</p></abstract>
        <draft>draft-smyshlyaev-tls13-gost-suites-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9367</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9368</doc-id>
        <title>Compatible Version Negotiation for QUIC</title>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>quic</kw>
            <kw>version</kw>
            <kw>negotiation</kw>
            <kw>compatible</kw>
            <kw>incompatible</kw>
            <kw>not quite tls</kw>
            <kw>tls-ng</kw>
        </keywords>
        <abstract><p>QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable.  This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version.  Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip.  This document updates RFC 8999.</p></abstract>
        <draft>draft-ietf-quic-version-negotiation-14</draft>
        <updates>
            <doc-id>RFC8999</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <doi>10.17487/RFC9368</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9369</doc-id>
        <title>QUIC Version 2</title>
        <author>
            <name>M. Duke</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.</p><p> Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.</p></abstract>
        <draft>draft-ietf-quic-v2-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>quic</wg_acronym>
        <doi>10.17487/RFC9369</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9370</doc-id>
        <title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>CJ. Tjhai</name>
        </author>
        <author>
            <name>M. Tomlinson</name>
        </author>
        <author>
            <name>G. Bartlett</name>
        </author>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <author>
            <name>D. Van Geest</name>
        </author>
        <author>
            <name>O. Garcia-Morchon</name>
        </author>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>post-quantum</kw>
            <kw>PQC</kw>
            <kw>hybrid</kw>
            <kw>hybridization</kw>
            <kw>hybrid key exchange</kw>
            <kw>key encapsulation</kw>
            <kw>quantum</kw>
            <kw>quantum-safe</kw>
            <kw>KEM</kw>
            <kw>PQ</kw>
        </keywords>
        <abstract><p>This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.</p><p> This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.</p><p> This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-multiple-ke-12</draft>
        <updates>
            <doc-id>RFC7296</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9370</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9371</doc-id>
        <title>Registration Procedures for Private Enterprise Numbers (PENs)</title>
        <author>
            <name>A. Baber</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>This document describes how Private Enterprise Numbers (PENs) are registered by IANA.  It shows how to request a new PEN and how to modify a current PEN.  It also gives a brief overview of PEN uses.</p></abstract>
        <draft>draft-pti-pen-registration-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9371</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9372</doc-id>
        <title>L-Band Digital Aeronautical Communications System (LDACS)</title>
        <author>
            <name>N. Mäurer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Gräupl</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Schmitt</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>Aeronautical Communications</kw>
            <kw>Data Link Technology</kw>
            <kw>Future Communications Infrastructure</kw>
            <kw>Reliable Wireless Technology</kw>
        </keywords>
        <abstract><p>This document gives an overview of the L-band Digital Aeronautical Communications System (LDACS) architecture, which provides a secure, scalable, and spectrum-efficient terrestrial data link for civil aviation.  LDACS is a scheduled and reliable multi-application cellular broadband system with support for IPv6.  It is part of a larger shift of flight guidance communication moving to IP-based communication.  High reliability and availability of IP connectivity over LDACS, as well as security, are therefore essential.  The intent of this document is to introduce LDACS to the IETF community, raise awareness on related activities inside and outside of the IETF, and to seek expertise in shaping the shift of aeronautics to IP.</p></abstract>
        <draft>draft-ietf-raw-ldacs-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>raw</wg_acronym>
        <doi>10.17487/RFC9372</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9373</doc-id>
        <title>EdDSA Value for IPSECKEY</title>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>IPSECKEY EdDSA</kw>
        </keywords>
        <abstract><p>This document assigns a value for Edwards-Curve Digital Signature Algorithm (EdDSA) Public Keys to the "IPSECKEY Resource Record Parameters" registry.</p></abstract>
        <draft>draft-moskowitz-ipsecme-ipseckey-eddsa-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9373</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9374</doc-id>
        <title>DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)</title>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>S. Card</name>
        </author>
        <author>
            <name>A. Wiethuechter</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>RID</kw>
        </keywords>
        <abstract><p>This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking.</p><p> Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement.</p><p> This document updates RFCs 7401 and 7343.</p></abstract>
        <draft>draft-ietf-drip-rid-37</draft>
        <updates>
            <doc-id>RFC7343</doc-id>
            <doc-id>RFC7401</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>drip</wg_acronym>
        <doi>10.17487/RFC9374</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9375</doc-id>
        <title>A YANG Data Model for Network and VPN Service Performance Monitoring</title>
        <author>
            <name>B. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Q. Wu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>B. Wen</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>VPN Performance Measurement Telemetry</kw>
        </keywords>
        <abstract><p>The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies.  This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers.</p></abstract>
        <draft>draft-ietf-opsawg-yang-vpn-service-pm-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9375</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9376</doc-id>
        <title>Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network</title>
        <author>
            <name>Q. Wang</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Valiveti</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Zheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. van Helvoort</name>
        </author>
        <author>
            <name>S. Belotti</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>B100G OTN</kw>
        </keywords>
        <abstract><p>This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709.</p></abstract>
        <draft>draft-ietf-ccamp-gmpls-otn-b100g-applicability-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <doi>10.17487/RFC9376</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9377</doc-id>
        <title>IS-IS Flood Reflection</title>
        <author>
            <name>T. Przygienda</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bowers</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>A. Sharma</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies.  Flood reflection permits topologies in which IS-IS Level 1 (L1) areas provide transit-forwarding for IS-IS Level 2 (L2) areas using all available L1 nodes internally.  It accomplishes this by creating L2 flood reflection adjacencies within each L1 area.  Those adjacencies are used to flood L2 Link State Protocol Data Units (LSPs) and are used in the L2 Shortest Path First (SPF) computation.  However, they are not ordinarily utilized for forwarding within the flood reflection cluster.  This arrangement gives the L2 topology significantly better scaling properties than prevalently used flat designs.  As an additional benefit, only those routers directly participating in flood reflection are required to support the feature.  This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network.</p></abstract>
        <draft>draft-ietf-lsr-isis-flood-reflection-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9377</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9378</doc-id>
        <title>In Situ Operations, Administration, and Maintenance (IOAM) Deployment</title>
        <author>
            <name>F. Brockners</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bhandari</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Bernier</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Telemetry</kw>
            <kw>Tracing</kw>
        </keywords>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network.  This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance.</p></abstract>
        <draft>draft-ietf-ippm-ioam-deployment-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9378</doi>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC9379</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC9380</doc-id>
        <title>Hashing to Elliptic Curves</title>
        <author>
            <name>A. Faz-Hernandez</name>
        </author>
        <author>
            <name>S. Scott</name>
        </author>
        <author>
            <name>N. Sullivan</name>
        </author>
        <author>
            <name>R. S. Wahby</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>145</page-count>
        <abstract><p>This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve.  This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-hash-to-curve-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9380</errata-url>
        <doi>10.17487/RFC9380</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9381</doc-id>
        <title>Verifiable Random Functions (VRFs)</title>
        <author>
            <name>S. Goldberg</name>
        </author>
        <author>
            <name>L. Reyzin</name>
        </author>
        <author>
            <name>D. Papadopoulos</name>
        </author>
        <author>
            <name>J. Včelák</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>public key cryptography</kw>
            <kw>hashing</kw>
            <kw>authenticated denial</kw>
        </keywords>
        <abstract><p>A Verifiable Random Function (VRF) is the public key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-vrf-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9381</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9382</doc-id>
        <title>SPAKE2, a Password-Authenticated Key Exchange</title>
        <author>
            <name>W. Ladd</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <abstract><p>This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password.  This method is compatible with any group, is computationally efficient, and has a security proof.  This document predated the Crypto Forum Research Group (CFRG) password-authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial.  Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2.  This document is a product of the Crypto Forum Research Group in the Internet Research Task Force (IRTF).</p></abstract>
        <draft>draft-irtf-cfrg-spake2-26</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9382</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9383</doc-id>
        <title>SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol</title>
        <author>
            <name>T. Taubert</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient.</p><p> This document was produced outside of the IETF and IRTF and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF.</p></abstract>
        <draft>draft-bar-cfrg-spake2plus-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9383</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9384</doc-id>
        <title>A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)</title>
        <author>
            <name>J. Haas</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections more quickly than the original protocol timers.</p><p> This document defines a subcode for the BGP Cease NOTIFICATION message (Section 6.7 of RFC 4271) for use when a BGP connection is being closed due to a BFD session going down.</p></abstract>
        <draft>draft-ietf-idr-bfd-subcode-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9384</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9385</doc-id>
        <title>Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>148</page-count>
        <keywords>
            <kw>Streebog</kw>
            <kw>Kuznyechik</kw>
            <kw>Magma</kw>
            <kw>MGM</kw>
        </keywords>
        <abstract><p>This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (called "GOST" algorithms). Use of GOST ciphers in IKEv2 is defined in RFC 9227. This document aims to define the use of GOST algorithms for the rest of the cryptographic transforms used in IKEv2.</p><p> This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.</p></abstract>
        <draft>draft-smyslov-ike2-gost-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9385</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9386</doc-id>
        <title>IPv6 Deployment Status</title>
        <author>
            <name>G. Fioccola</name>
        </author>
        <author>
            <name>P. Volpato</name>
        </author>
        <author>
            <name>J. Palet Martinez</name>
        </author>
        <author>
            <name>G. Mishra</name>
        </author>
        <author>
            <name>C. Xie</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Survey</kw>
            <kw>Challenges</kw>
            <kw>IPv6-only</kw>
            <kw>Overlay</kw>
            <kw>Underlay</kw>
            <kw>IPv4aaS</kw>
        </keywords>
        <abstract><p>This document provides an overview of the status of IPv6 deployment in 2022.  Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6.  It obsoletes RFC 6036.</p></abstract>
        <draft>draft-ietf-v6ops-ipv6-deployment-10</draft>
        <obsoletes>
            <doc-id>RFC6036</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC9386</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9387</doc-id>
        <title>Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry</title>
        <author>
            <name>Y. Hayashi</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>L. Su</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>DOTS</kw>
            <kw>Telemetry</kw>
            <kw>Use cases</kw>
            <kw>DDoS</kw>
            <kw>Automation</kw>
        </keywords>
        <abstract><p>DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network.  This document presents sample use cases for DOTS telemetry.  It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques.</p></abstract>
        <draft>draft-ietf-dots-telemetry-use-cases-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>dots</wg_acronym>
        <doi>10.17487/RFC9387</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9388</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union</title>
        <author>
            <name>N. Sopher</name>
        </author>
        <author>
            <name>S. Mishra</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Request Routing</kw>
            <kw>Footprint and Capabilities Semantics</kw>
        </keywords>
        <abstract><p>Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN).  RFC 8006 defines footprint types that are used for footprint objects as part of the Metadata interface (MI).  The footprint types are also used for the Footprint &amp; Capabilities Advertisement interface (FCI) as defined in RFC 8008.  This document defines two new footprint types.  The first footprint type defined is an ISO 3166-2 country subdivision code.  Defining this country subdivision code improves granularity for delegation as compared to the ISO 3166-1 country code footprint type defined in RFC 8006.  The ISO 3166-2 country subdivision code is also added as a new entity domain type in the "ALTO Entity Domain Types" registry defined in Section 7.4 of RFC 9241.  The second footprint type defines a footprint union to aggregate footprint objects.  This allows for additive semantics over the narrowing semantics defined in Appendix B of RFC 8008 and therefore updates RFC 8008.  The two new footprint types are based on the requirements raised by Open Caching but are also applicable to CDNI use cases in general.</p></abstract>
        <draft>draft-ietf-cdni-additional-footprint-types-12</draft>
        <updates>
            <doc-id>RFC8008</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC9388</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9389</doc-id>
        <title>Nominating Committee Eligibility</title>
        <author>
            <name>M. Duke</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>NomCom</kw>
        </keywords>
        <abstract><p>The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees.  RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings.  In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility.  This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance.  This document obsoletes RFCs 8788 and 8989.</p></abstract>
        <draft>draft-ietf-elegy-rfc8989bis-05</draft>
        <obsoletes>
            <doc-id>RFC8788</doc-id>
            <doc-id>RFC8989</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC8713</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0010</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>elegy</wg_acronym>
        <doi>10.17487/RFC9389</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9390</doc-id>
        <title>Diameter Group Signaling</title>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>M. Liebsch</name>
        </author>
        <author>
            <name>L. Morand</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions.  In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently.  The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group.  In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges.  This document specifies the Diameter protocol extensions to achieve this signaling optimization.</p></abstract>
        <draft>draft-ietf-dime-group-signaling-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dime</wg_acronym>
        <doi>10.17487/RFC9390</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9391</doc-id>
        <title>Static Context Header Compression over Narrowband Internet of Things</title>
        <author>
            <name>E. Ramos</name>
        </author>
        <author>
            <name>A. Minaburo</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SCHC</kw>
            <kw>Header Compression</kw>
            <kw>Fragmentation</kw>
            <kw>3GPP</kw>
            <kw>5G</kw>
            <kw>IoT</kw>
            <kw>Sensor network</kw>
            <kw>cellular network</kw>
            <kw>LTE</kw>
            <kw>LTE-M</kw>
        </keywords>
        <abstract><p>This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).</p><p> This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures.</p></abstract>
        <draft>draft-ietf-lpwan-schc-over-nbiot-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC9391</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9392</doc-id>
        <title>Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>Congestion Control</kw>
            <kw>VoIP</kw>
            <kw>Video Conferencing</kw>
        </keywords>
        <abstract><p>This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for implementing congestion control for unicast multimedia applications.</p></abstract>
        <draft>draft-ietf-rmcat-rtp-cc-feedback-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>tsv</area>
        <wg_acronym>rmcat</wg_acronym>
        <doi>10.17487/RFC9392</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9393</doc-id>
        <title>Concise Software Identification Tags</title>
        <author>
            <name>H. Birkholz</name>
        </author>
        <author>
            <name>J. Fitzgerald-McKay</name>
        </author>
        <author>
            <name>C. Schmidt</name>
        </author>
        <author>
            <name>D. Waltermire</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>61</page-count>
        <abstract><p>ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles.  SWID tag representations can be too large for devices with network and storage constraints.  This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags.  CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format.</p></abstract>
        <draft>draft-ietf-sacm-coswid-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>sacm</wg_acronym>
        <doi>10.17487/RFC9393</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9394</doc-id>
        <title>IMAP PARTIAL Extension for Paged SEARCH and FETCH</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>A. P. Achuthan</name>
        </author>
        <author>
            <name>V. Nagulakonda</name>
        </author>
        <author>
            <name>L. Alves</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>The PARTIAL extension of the Internet Message Access Protocol (see RFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches.</p><p> This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFCs 4731 and 9051.</p><p> This document updates RFCs 4731 and 5267.</p></abstract>
        <draft>draft-ietf-extra-imap-partial-04</draft>
        <updates>
            <doc-id>RFC4731</doc-id>
            <doc-id>RFC5267</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9394</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9395</doc-id>
        <title>Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms</title>
        <author>
            <name>P. Wouters</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IKEv1</kw>
            <kw>IKEv2</kw>
            <kw>IPsec</kw>
            <kw>IKE</kw>
        </keywords>
        <abstract><p>Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs 2407, 2408, and 2409 have been moved to Historic status.  This document updates RFCs 8221 and 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1 and are not specified or commonly implemented for IKEv2.  This document further updates the IANA registries for IKEv2 "Transform Type Values" by adding a "Status" column where the deprecation status can be listed.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev1-algo-to-historic-09</draft>
        <updates>
            <doc-id>RFC8221</doc-id>
            <doc-id>RFC8247</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9395</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9396</doc-id>
        <title>OAuth 2.0 Rich Authorization Requests</title>
        <author>
            <name>T. Lodderstedt</name>
        </author>
        <author>
            <name>J. Richer</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>security</kw>
            <kw>oauth2</kw>
        </keywords>
        <abstract><p>This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages.</p></abstract>
        <draft>draft-ietf-oauth-rar-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9396</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9397</doc-id>
        <title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>
        <author>
            <name>M. Pei</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>D. Wheeler</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>trusted application</kw>
            <kw>trusted component</kw>
            <kw>TEE</kw>
            <kw>trust anchor</kw>
            <kw>TAM</kw>
            <kw>confidential computing</kw>
        </keywords>
        <abstract><p>A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment.  This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.</p></abstract>
        <draft>draft-ietf-teep-architecture-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>teep</wg_acronym>
        <doi>10.17487/RFC9397</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9398</doc-id>
        <title>A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices</title>
        <author>
            <name>H. Zhao</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>Y. Liu</name>
        </author>
        <author>
            <name>M. Panchanathan</name>
        </author>
        <author>
            <name>M. Sivakumar</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>IGMP Proxy</kw>
            <kw>MLD Proxy</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) Proxy devices.  The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-pim-igmp-mld-proxy-yang-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9398</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9399</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>
        <author>
            <name>L. Rosenthol</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>X.509</kw>
            <kw>Public Key Infrastructure</kw>
            <kw>authentication</kw>
            <kw>security identification</kw>
            <kw>certificates</kw>
        </keywords>
        <abstract><p>This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.  This document obsoletes RFCs 3709 and 6170.</p></abstract>
        <draft>draft-ietf-lamps-rfc3709bis-10</draft>
        <obsoletes>
            <doc-id>RFC3709</doc-id>
            <doc-id>RFC6170</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9399</errata-url>
        <doi>10.17487/RFC9399</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9400</doc-id>
        <title>Guidelines for the Organization of Fully Online Meetings</title>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>M. Duke</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda.  These guidelines are based on the experience gained by holding online meetings during the COVID-19 pandemic in 2020 and 2021.</p></abstract>
        <draft>draft-ietf-shmoo-online-meeting-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>shmoo</wg_acronym>
        <doi>10.17487/RFC9400</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9401</doc-id>
        <title>The Addition of the Death (DTH) Flag to TCP</title>
        <author>
            <name>S. Toyosawa</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>Control bits</kw>
            <kw>flags</kw>
        </keywords>
        <abstract><p>This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header.  The flag is designed to make TCP session narratives smooth and attractive.</p></abstract>
        <draft>draft-deathflag-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9401</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9402</doc-id>
        <title>Concat Notation</title>
        <author>
            <name>M. Basaglia</name>
        </author>
        <author>
            <name>J. Bernards</name>
        </author>
        <author>
            <name>J. Maas</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>cat</kw>
            <kw>container</kw>
        </keywords>
        <abstract><p>This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions.</p></abstract>
        <draft>draft-glax-concat-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9402</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9403</doc-id>
        <title>A YANG Data Model for RIB Extensions</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>configuration</kw>
            <kw>IPv6 Router Advertisements</kw>
            <kw>NETCONF</kw>
            <kw>RESTCONF</kw>
            <kw>YANG</kw>
            <kw>Routing</kw>
            <kw>RIB</kw>
        </keywords>
        <abstract><p>A Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state.</p><p> RFC 8349 defines the basic building blocks for the RIB data model, and this model augments it to support multiple next hops (aka paths) for each route as well as additional attributes.</p></abstract>
        <draft>draft-ietf-rtgwg-yang-rib-extend-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <doi>10.17487/RFC9403</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9404</doc-id>
        <title>JSON Meta Application Protocol (JMAP) Blob Management Extension</title>
        <author>
            <name>B. Gondwana</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>jmap</kw>
        </keywords>
        <abstract><p>The JSON Meta Application Protocol (JMAP) base protocol (RFC 8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on a defined endpoint. This binary data is called a "blob".</p><p> This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request.</p><p> This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types.</p></abstract>
        <draft>draft-ietf-jmap-blob-18</draft>
        <updates>
            <doc-id>RFC8620</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9404</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9405</doc-id>
        <title>AI Sarcasm Detection: Insult Your AI without Offending It</title>
        <author>
            <name>C. GPT</name>
        </author>
        <author>
            <name>R. L. Barnes</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Artificial intelligence</kw>
            <kw>ChatGPT</kw>
            <kw>Large Language Models</kw>
            <kw>Sarcasm</kw>
            <kw>Sentiment analysis</kw>
        </keywords>
        <abstract><p>This RFC proposes a framework for detecting sarcasm in AI systems and provides guidelines for using sarcasm without causing offense.  By training AI systems to identify linguistic patterns that indicate sarcasm, we can improve their understanding of human communication.  The guidelines offer a lighthearted approach to using sarcasm in a way that is both effective and respectful, without crossing the line into offensive language.</p></abstract>
        <draft>draft-chatgpt-aisdp-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9405</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9406</doc-id>
        <title>HyStart++: Modified Slow Start for TCP</title>
        <author>
            <name>P. Balasubramanian</name>
        </author>
        <author>
            <name>Y. Huang</name>
        </author>
        <author>
            <name>M. Olson</name>
        </author>
        <date>
            <month>May</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>TCP</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract><p>This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms.  Slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance.  HyStart++ uses increase in round-trip delay as a heuristic to find an exit point before possible overshoot.  It also adds a mitigation to prevent jitter from causing premature slow start exit.</p></abstract>
        <draft>draft-ietf-tcpm-hystartplusplus-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC9406</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9407</doc-id>
        <title>Tetrys: An On-the-Fly Network Coding Protocol</title>
        <author>
            <name>J. Detchart</name>
        </author>
        <author>
            <name>E. Lochin</name>
        </author>
        <author>
            <name>J. Lacan</name>
        </author>
        <author>
            <name>V. Roca</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Network Coding</kw>
        </keywords>
        <abstract><p>This document describes Tetrys, which is an on-the-fly network coding protocol that can be used to transport delay-sensitive and loss-sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay thanks to the transmission of coded packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.</p><p> This document is a product of the Coding for Efficient NetWork Communications Research Group (NWCRG). It conforms to the NWCRG taxonomy described in RFC 8406.</p></abstract>
        <draft>draft-irtf-nwcrg-tetrys-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9407</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9408</doc-id>
        <title>A YANG Network Data Model for Service Attachment Points (SAPs)</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>S. Barguil</name>
        </author>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>V. Lopez</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Service Infrastructure</kw>
            <kw>User Network Interface</kw>
            <kw>UNI</kw>
            <kw>NNI</kw>
            <kw>Network-to-Network Interface</kw>
            <kw>Inter-AS VPN</kw>
            <kw>CE</kw>
            <kw>PE</kw>
            <kw>Attachment Circuit</kw>
            <kw>Service Delivery Point</kw>
            <kw>Automation</kw>
            <kw>Service Delivery</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks).</p><p> This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model.</p></abstract>
        <draft>draft-ietf-opsawg-sap-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9408</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9409</doc-id>
        <title>The 'sip-trunking-capability' Link Relation Type</title>
        <author>
            <name>K. Inamdar</name>
        </author>
        <author>
            <name>S. Narayanan</name>
        </author>
        <author>
            <name>D. Engi</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>SIP</kw>
            <kw>Session Initiation Protocol</kw>
            <kw>automatic peering</kw>
            <kw>WebFinger</kw>
            <kw>capability set</kw>
        </keywords>
        <abstract><p>This Informational document defines the 'sip-trunking-capability'
link relation type that may be used by an enterprise telephony
Session Initiation Protocol (SIP) network to retrieve a SIP trunking
capability set document, which contains the capabilities and
configuration requirements of an Internet Telephony Service Provider
(ITSP).  These technical requirements allow for seamless peering
between SIP-based enterprise telephony networks and the ITSP.</p></abstract>
        <draft>draft-ietf-asap-siptrunkingcapability-link-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>asap</wg_acronym>
        <doi>10.17487/RFC9409</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9410</doc-id>
        <title>Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR)</title>
        <author>
            <name>C. Wendt</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Identity</kw>
            <kw>multiple errors</kw>
            <kw>passport</kw>
            <kw>reason header field</kw>
        </keywords>
        <abstract><p>This document extends the current error-handling procedures for mapping of verification failure reasons to 4xx codes for Secure Telephone Identity Revisited (STIR) and the Authenticated Identity Management in the Session Initiation Protocol (SIP).  It extends the ability to use the Reason header field as an option for conveying an error associated with an Identity header field to the upstream authentication service when local policy dictates that the call should continue in the presence of a verification failure.  This document also defines procedures that enable a failure reason to be mapped to a specific Identity header field for scenarios that use multiple Identity header fields, where some may have errors and others may not.  The handling of those situations is also defined.</p></abstract>
        <draft>draft-ietf-stir-identity-header-errors-handling-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC9410</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9411</doc-id>
        <title>Benchmarking Methodology for Network Security Device Performance</title>
        <author>
            <name>B. Balarajah</name>
        </author>
        <author>
            <name>C. Rossenhoevel</name>
        </author>
        <author>
            <name>B. Monkman</name>
        </author>
        <date>
            <month>March</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>51</page-count>
        <keywords>
            <kw>NGFW</kw>
            <kw>NGIPS</kw>
            <kw>benchmarking</kw>
            <kw>performance testing</kw>
            <kw>security testing</kw>
        </keywords>
        <abstract><p>This document provides benchmarking terminology and methodology for next-generation network security devices, including next-generation firewalls (NGFWs) and next-generation intrusion prevention systems (NGIPSs).  The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFWs and NGIPSs. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security-centric network application use cases.  As a result, this document makes RFC 3511 obsolete.</p></abstract>
        <draft>draft-ietf-bmwg-ngfw-performance-15</draft>
        <obsoletes>
            <doc-id>RFC3511</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC9411</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9412</doc-id>
        <title>The ORIGIN Extension in HTTP/3</title>
        <author>
            <name>M. Bishop</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered.  This document describes the ORIGIN frame for HTTP/3.</p></abstract>
        <draft>draft-ietf-httpbis-origin-h3-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9412</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9413</doc-id>
        <title>Maintaining Robust Protocols</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>postel</kw>
            <kw>law</kw>
            <kw>robustness</kw>
            <kw>principle</kw>
            <kw>wrong</kw>
            <kw>tolerance</kw>
        </keywords>
        <abstract><p>The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem.</p><p> The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls.</p></abstract>
        <draft>draft-iab-protocol-maintenance-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9413</errata-url>
        <doi>10.17487/RFC9413</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9414</doc-id>
        <title>Unfortunate History of Transient Numeric Identifiers</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>I. Arce</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>security</kw>
            <kw>vulnerability</kw>
            <kw>algorithm</kw>
            <kw>attack</kw>
            <kw>fingerprinting</kw>
        </keywords>
        <abstract><p>This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it.  It provides empirical evidence that advice in this area is warranted.  This document is a product of the Privacy Enhancements and Assessments Research Group (PEARG) in the IRTF.</p></abstract>
        <draft>draft-irtf-pearg-numeric-ids-history-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9414</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9415</doc-id>
        <title>On the Generation of Transient Numeric Identifiers</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>I. Arce</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>security</kw>
            <kw>vulnerability</kw>
            <kw>algorithm</kw>
            <kw>attack</kw>
            <kw>fingerprinting</kw>
        </keywords>
        <abstract><p>This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met.  Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers.  Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties.  This document is a product of the Privacy Enhancements and Assessments Research Group (PEARG) in the IRTF.</p></abstract>
        <draft>draft-irtf-pearg-numeric-ids-generation-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9415</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9416</doc-id>
        <title>Security Considerations for Transient Numeric Identifiers Employed in Network Protocols</title>
        <author>
            <name>F. Gont</name>
        </author>
        <author>
            <name>I. Arce</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>security</kw>
            <kw>vulnerability</kw>
            <kw>algorithm</kw>
            <kw>attack</kw>
            <kw>fingerprinting</kw>
        </keywords>
        <abstract><p>Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring.  Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues.  This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations.</p></abstract>
        <draft>draft-gont-numeric-ids-sec-considerations-11</draft>
        <updates>
            <doc-id>RFC3552</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0072</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9416</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9417</doc-id>
        <title>Service Assurance for Intent-Based Networking Architecture</title>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>J. Quilbeuf</name>
        </author>
        <author>
            <name>D. Lopez</name>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <author>
            <name>T. Arumugam</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <abstract><p>This document describes an architecture that provides some assurance that service instances are running as expected.  As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements.  This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component.</p></abstract>
        <draft>draft-ietf-opsawg-service-assurance-architecture-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9417</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9418</doc-id>
        <title>A YANG Data Model for Service Assurance</title>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>J. Quilbeuf</name>
        </author>
        <author>
            <name>P. Lucente</name>
        </author>
        <author>
            <name>P. Fasano</name>
        </author>
        <author>
            <name>T. Arumugam</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>38</page-count>
        <keywords>
            <kw>health</kw>
            <kw>SAIN</kw>
            <kw>subservice</kw>
            <kw>symptom</kw>
            <kw>telemetry</kw>
        </keywords>
        <abstract><p>This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. The companion document, "Service Assurance for Intent-Based Networking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services.</p><p> The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</p></abstract>
        <draft>draft-ietf-opsawg-service-assurance-yang-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9418</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9419</doc-id>
        <title>Considerations on Application - Network Collaboration Using Path Signals</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document discusses principles for designing mechanisms that use or provide path signals and calls for standards action in specific valuable cases.  RFC 8558 describes path signals as messages to or from on-path elements and points out that visible information will be used whether or not it is intended as a signal.  The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing.  These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path.</p></abstract>
        <draft>draft-iab-path-signals-collaboration-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9419</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9420</doc-id>
        <title>The Messaging Layer Security (MLS) Protocol</title>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>B. Beurdouche</name>
        </author>
        <author>
            <name>R. Robert</name>
        </author>
        <author>
            <name>J. Millican</name>
        </author>
        <author>
            <name>E. Omara</name>
        </author>
        <author>
            <name>K. Cohn-Gordon</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>132</page-count>
        <abstract><p>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages.  Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time.  In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</p></abstract>
        <draft>draft-ietf-mls-protocol-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mls</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9420</errata-url>
        <doi>10.17487/RFC9420</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9421</doc-id>
        <title>HTTP Message Signatures</title>
        <author>
            <name>A. Backman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Sporny</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>95</page-count>
        <keywords>
            <kw>PKI</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message.  This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier.  This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</p></abstract>
        <draft>draft-ietf-httpbis-message-signatures-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9421</errata-url>
        <doi>10.17487/RFC9421</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9422</doc-id>
        <title>The LIMITS SMTP Service Extension</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>SMTP</kw>
            <kw>LMTP</kw>
            <kw>Message Submission</kw>
            <kw>ESMTP</kw>
            <kw>Extension</kw>
        </keywords>
        <abstract><p>This document defines a LIMITS extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP).  It also defines an associated limit registry.  The extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session.  The client is then able to adapt its behavior in order to conform to those limits.</p></abstract>
        <draft>draft-freed-smtp-limits-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9422</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9423</doc-id>
        <title>Constrained RESTful Environments (CoRE) Target Attributes Registry</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>CoAP</kw>
            <kw>Web Linking</kw>
            <kw>Resource Discovery</kw>
        </keywords>
        <abstract><p>The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the Resource Directory (RD) (RFC 9176).</p><p> Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry.</p></abstract>
        <draft>draft-ietf-core-target-attr-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9423</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9424</doc-id>
        <title>Indicators of Compromise (IoCs) and Their Role in Attack Defence</title>
        <author>
            <name>K. Paine</name>
        </author>
        <author>
            <name>O. Whitehouse</name>
        </author>
        <author>
            <name>J. Sellwood</name>
        </author>
        <author>
            <name>A. Shaw</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>IOC</kw>
            <kw>Attack Defence</kw>
        </keywords>
        <abstract><p>Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints.  This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use.  It highlights the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security.</p></abstract>
        <draft>draft-ietf-opsec-indicators-of-compromise-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9424</errata-url>
        <doi>10.17487/RFC9424</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9425</doc-id>
        <title>JSON Meta Application Protocol (JMAP) for Quotas</title>
        <author>
            <name>R. Cordier</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
            <kw>email</kw>
            <kw>quotas</kw>
        </keywords>
        <abstract><p>This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP).</p></abstract>
        <draft>draft-ietf-jmap-quotas-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9425</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9426</doc-id>
        <title>BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport</title>
        <author>
            <name>S. Yang</name>
        </author>
        <author>
            <name>X. Huang</name>
        </author>
        <author>
            <name>R. Yeung</name>
        </author>
        <author>
            <name>J. Zao</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>BATS code</kw>
            <kw>multi-hop</kw>
        </keywords>
        <abstract><p>In general, linear network coding can improve the network communication performance in terms of throughput, latency, and reliability.  BATched Sparse (BATS) code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code and batch-based linear network coding as the inner code.  This document describes a baseline BATS coding scheme for communication through multi-hop networks and discusses the related research issues towards a more sophisticated BATS coding scheme.  This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG).</p></abstract>
        <draft>draft-irtf-nwcrg-bats-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9426</errata-url>
        <doi>10.17487/RFC9426</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9427</doc-id>
        <title>TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>June</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>TTLS</kw>
            <kw>PEAP. FAST</kw>
            <kw>TEAP</kw>
        </keywords>
        <abstract><p>The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been updated for TLS 1.3 in RFC 9190.  Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via Secure Tunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC 5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC 7170).  It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend on TLS as well.  This document updates those methods in order to use the new key derivation methods available in TLS 1.3.  Additional changes necessitated by TLS 1.3 are also discussed.</p></abstract>
        <draft>draft-ietf-emu-tls-eap-types-13</draft>
        <updates>
            <doc-id>RFC4851</doc-id>
            <doc-id>RFC5281</doc-id>
            <doc-id>RFC7170</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC9427</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9428</doc-id>
        <title>Transmission of IPv6 Packets over Near Field Communication</title>
        <author>
            <name>Y. Choi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y-G. Hong</name>
        </author>
        <author>
            <name>J-S. Youn</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Near Field Communication</kw>
            <kw>NFC</kw>
            <kw>6LowPAN</kw>
            <kw>IPv6</kw>
            <kw>Adaptation Layer</kw>
            <kw>IoT</kw>
            <kw>Internet of Things</kw>
        </keywords>
        <abstract><p>Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart.  NFC standards cover communication protocols and data exchange formats and are based on existing Radio Frequency Identification (RFID) standards, including ISO/IEC 14443 and FeliCa.  The standards include ISO/IEC 18092 and those defined by the NFC Forum.  The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices.  This document describes how IPv6 is transmitted over NFC using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.</p></abstract>
        <draft>draft-ietf-6lo-nfc-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC9428</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9429</doc-id>
        <title>JavaScript Session Establishment Protocol (JSEP)</title>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>E. Rescorla</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>86</page-count>
        <keywords>
            <kw>webrtc</kw>
            <kw>sdp</kw>
            <kw>negotiation</kw>
            <kw>signaling</kw>
            <kw>peerconnection</kw>
            <kw>api</kw>
            <kw>ice</kw>
            <kw>rtp</kw>
            <kw>offer</kw>
            <kw>answer</kw>
        </keywords>
        <abstract><p>This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.</p><p> This specification obsoletes RFC 8829.</p></abstract>
        <draft>draft-uberti-rtcweb-rfc8829bis-05</draft>
        <obsoletes>
            <doc-id>RFC8829</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>rtcweb</wg_acronym>
        <doi>10.17487/RFC9429</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9430</doc-id>
        <title>Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)</title>
        <author>
            <name>O. Bergmann</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Internet of Things (IoT)</kw>
            <kw>Internet of Things</kw>
            <kw>IOT</kw>
            <kw>OAuth</kw>
            <kw>Access Token</kw>
        </keywords>
        <abstract><p>This document updates "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS.</p></abstract>
        <draft>draft-ietf-ace-extend-dtls-authorize-07</draft>
        <updates>
            <doc-id>RFC9202</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9430</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9431</doc-id>
        <title>Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework</title>
        <author>
            <name>C. Sengul</name>
        </author>
        <author>
            <name>A. Kirby</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>publish-subscribe</kw>
            <kw>authorization information format</kw>
        </keywords>
        <abstract><p>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT).  Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients.  The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.</p></abstract>
        <draft>draft-ietf-ace-mqtt-tls-profile-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9431</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9432</doc-id>
        <title>DNS Catalog Zones</title>
        <author>
            <name>P. van Dijk</name>
        </author>
        <author>
            <name>L. Peltan</name>
        </author>
        <author>
            <name>O. Surý</name>
        </author>
        <author>
            <name>W. Toorop</name>
        </author>
        <author>
            <name>C.R. Monshouwer</name>
        </author>
        <author>
            <name>P. Thomassen</name>
        </author>
        <author>
            <name>A. Sargsyan</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes a method for automatic DNS zone provisioning among DNS primary and secondary name servers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones.</p></abstract>
        <draft>draft-ietf-dnsop-dns-catalog-zones-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9432</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9433</doc-id>
        <title>Segment Routing over IPv6 for the Mobile User Plane</title>
        <author>
            <name>S. Matsushima</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>M. Kohno</name>
        </author>
        <author>
            <name>P. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>SRv6 mobility</kw>
            <kw>MUP</kw>
            <kw>CMUP</kw>
            <kw>srv6 3gpp</kw>
            <kw>GTP</kw>
        </keywords>
        <abstract><p>This document discusses the applicability of Segment Routing over IPv6 (SRv6) to the user plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user plane, providing flexibility, end-to-end network slicing, and Service Level Agreement (SLA) control for various applications.</p><p> This document discusses how SRv6 could be used as the user plane of mobile networks. This document also specifies the SRv6 Endpoint Behaviors required for mobility use cases.</p></abstract>
        <draft>draft-ietf-dmm-srv6-mobile-uplane-24</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dmm</wg_acronym>
        <doi>10.17487/RFC9433</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9434</doc-id>
        <title>Drone Remote Identification Protocol (DRIP) Architecture</title>
        <author>
            <name>S. Card</name>
        </author>
        <author>
            <name>A. Wiethuechter</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <author>
            <name>S. Zhao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>UAS RID</kw>
            <kw>F3411</kw>
            <kw>DRIP</kw>
            <kw>drone</kw>
        </keywords>
        <abstract><p>This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications.  This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153).</p></abstract>
        <draft>draft-ietf-drip-arch-31</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>drip</wg_acronym>
        <doi>10.17487/RFC9434</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9435</doc-id>
        <title>Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP)</title>
        <author>
            <name>A. Custura</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>R. Secchi</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>DSCP</kw>
            <kw>DiffServ Codepoints</kw>
        </keywords>
        <abstract><p>This document discusses considerations for assigning a new recommended Differentiated Services Code Point (DSCP) for a standard Per-Hop Behavior (PHB).  It considers the common observed re-marking behaviors that the Diffserv field might be subjected to along an Internet path.  It also notes some implications of using a specific DSCP.</p></abstract>
        <draft>draft-ietf-tsvwg-dscp-considerations-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9435</errata-url>
        <doi>10.17487/RFC9435</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9436</doc-id>
        <title>PIM Message Type Space Extension and Reserved Bits</title>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Multicast PIM</kw>
        </keywords>
        <abstract><p>The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and extends the PIM type space.</p><p> This document updates RFCs 7761 and 3973 by defining the use of the Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the bits for each PIM message.</p><p> This document obsoletes RFC 8736.</p></abstract>
        <draft>draft-ietf-pim-rfc8736bis-04</draft>
        <obsoletes>
            <doc-id>RFC8736</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3973</doc-id>
            <doc-id>RFC5015</doc-id>
            <doc-id>RFC5059</doc-id>
            <doc-id>RFC6754</doc-id>
            <doc-id>RFC7761</doc-id>
            <doc-id>RFC8364</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9436</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9437</doc-id>
        <title>Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)</title>
        <author>
            <name>A. Rodriguez-Natal</name>
        </author>
        <author>
            <name>V. Ermagan</name>
        </author>
        <author>
            <name>A. Cabellos</name>
        </author>
        <author>
            <name>S. Barkai</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>lisp</kw>
            <kw>publish</kw>
            <kw>subscribe</kw>
            <kw>subscription</kw>
            <kw>sdn</kw>
            <kw>nfv</kw>
        </keywords>
        <abstract><p>This document specifies an extension to the Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation.</p></abstract>
        <draft>draft-ietf-lisp-pubsub-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9437</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9438</doc-id>
        <title>CUBIC for Fast and Long-Distance Networks</title>
        <author>
            <name>L. Xu</name>
        </author>
        <author>
            <name>S. Ha</name>
        </author>
        <author>
            <name>I. Rhee</name>
        </author>
        <author>
            <name>V. Goel</name>
        </author>
        <author>
            <name>L. Eggert</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Congestion control</kw>
            <kw>large BDP</kw>
            <kw>window scalability</kw>
            <kw>RTT fairness</kw>
        </keywords>
        <abstract><p>CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.</p><p> This document updates the specification of CUBIC to include algorithmic improvements based on these implementations and recent academic work. Based on the extensive deployment experience with CUBIC, this document also moves the specification to the Standards Track and obsoletes RFC 8312. This document also updates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavior.</p></abstract>
        <draft>draft-ietf-tcpm-rfc8312bis-15</draft>
        <obsoletes>
            <doc-id>RFC8312</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5681</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9438</errata-url>
        <doi>10.17487/RFC9438</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9439</doc-id>
        <title>Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics</title>
        <author>
            <name>Q. Wu</name>
        </author>
        <author>
            <name>Y. Yang</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>S. Randriamasy</name>
        </author>
        <author>
            <name>L. Contreras</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>JavaScript Object Notation</kw>
            <kw>Application-Layer Traffic Optimization</kw>
        </keywords>
        <abstract><p>The cost metric is a basic concept in Application-Layer Traffic
Optimization (ALTO), and different applications may use different
types of cost metrics. Since the ALTO base protocol (RFC 7285)
defines only a single cost metric (namely, the generic "routingcost"
metric), if an application wants to issue a cost map or an endpoint
cost request in order to identify a resource provider that offers
better performance metrics (e.g., lower delay or loss rate), the base
protocol does not define the cost metric to be used.</p><p> This document addresses this issue by extending the specification to
provide a variety of network performance metrics, including network
delay, delay variation (a.k.a. jitter), packet loss rate, hop count,
and bandwidth.</p><p> There are multiple sources (e.g., estimations based on measurements
or a Service Level Agreement) available for deriving a performance
metric. This document introduces an additional "cost-context" field
to the ALTO "cost-type" field to convey the source of a performance
metric.</p></abstract>
        <draft>draft-ietf-alto-performance-metrics-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC9439</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9440</doc-id>
        <title>Client-Cert HTTP Header Field</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>M. Bishop</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>http</kw>
            <kw>client certificate</kw>
        </keywords>
        <abstract><p>This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner.</p></abstract>
        <draft>draft-ietf-httpbis-client-cert-field-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9440</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9441</doc-id>
        <title>Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)</title>
        <author>
            <name>J. Zúñiga</name>
        </author>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>S. Aguilar</name>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <author>
            <name>S. Céspedes</name>
        </author>
        <author>
            <name>D. Wistuba</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>SCHC</kw>
            <kw>LPWAN</kw>
            <kw>IoT</kw>
            <kw>Fragmentation</kw>
            <kw>Reliable Delivery</kw>
            <kw>Link Layer Protocols</kw>
            <kw>Cross-Layer Protocols</kw>
            <kw>Adaptation Layer</kw>
            <kw>Acknowledgment</kw>
            <kw>Sigfox</kw>
            <kw>LoRaWAN</kw>
            <kw>NB-IoT</kw>
            <kw>Compound ACK</kw>
        </keywords>
        <abstract><p>This document updates the Static Context Header Compression (SCHC) and fragmentation protocol (RFC 8724) and the corresponding YANG module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK) message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode, by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK).</p><p> Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low-Power Wide Area Network (LPWAN) technologies defined in RFC 8376, which are Sigfox, Long Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w.</p></abstract>
        <draft>draft-ietf-lpwan-schc-compound-ack-17</draft>
        <updates>
            <doc-id>RFC8724</doc-id>
            <doc-id>RFC9363</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC9441</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9442</doc-id>
        <title>Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN)</title>
        <author>
            <name>J. Zúñiga</name>
        </author>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>S. Aguilar</name>
        </author>
        <author>
            <name>L. Toutain</name>
        </author>
        <author>
            <name>S. Céspedes</name>
        </author>
        <author>
            <name>D. Wistuba</name>
        </author>
        <author>
            <name>J. Boite</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>IoT</kw>
            <kw>Sigfox</kw>
            <kw>SCHC</kw>
            <kw>LPWAN</kw>
            <kw>fragmentation</kw>
            <kw>Reliable Delivery</kw>
            <kw>Link Layer Protocols</kw>
            <kw>Cross-Layer Protocols</kw>
            <kw>Adaptation Layer</kw>
        </keywords>
        <abstract><p>The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed for Low-Power Wide Area Network (LPWAN) technologies.  This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation.</p></abstract>
        <draft>draft-ietf-lpwan-schc-over-sigfox-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>lpwan</wg_acronym>
        <doi>10.17487/RFC9442</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9443</doc-id>
        <title>Multiplexing Scheme Updates for QUIC</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>G. Salgueiro</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>ZRTP</kw>
            <kw>STUN</kw>
            <kw>TURN</kw>
            <kw>DTLS</kw>
        </keywords>
        <abstract><p>RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port.  This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket.</p></abstract>
        <draft>draft-ietf-avtcore-rfc7983bis-09</draft>
        <updates>
            <doc-id>RFC5764</doc-id>
            <doc-id>RFC7983</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9443</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9444</doc-id>
        <title>Automated Certificate Management Environment (ACME) for Subdomains</title>
        <author>
            <name>O. Friel</name>
        </author>
        <author>
            <name>R. Barnes</name>
        </author>
        <author>
            <name>T. Hollebeek</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document specifies how Automated Certificate Management Environment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority.  Additionally, this document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof.</p></abstract>
        <draft>draft-ietf-acme-subdomains-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC9444</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9445</doc-id>
        <title>RADIUS Extensions for DHCP-Configured Services</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>redirection</kw>
            <kw>subscriber policies</kw>
            <kw>differentiated service</kw>
            <kw>DNS</kw>
            <kw>DoH</kw>
            <kw>DoT</kw>
            <kw>DoQ</kw>
            <kw>QUIC</kw>
            <kw>Encryption</kw>
            <kw>Service delivery</kw>
            <kw>Service provisioning</kw>
            <kw>service activation</kw>
            <kw>policies</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract><p>This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are covered.</p><p> Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption.</p></abstract>
        <draft>draft-ietf-opsawg-add-encrypted-dns-12</draft>
        <updates>
            <doc-id>RFC4014</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9445</errata-url>
        <doi>10.17487/RFC9445</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9446</doc-id>
        <title>Reflections on Ten Years Past the Snowden Revelations</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>F. Badii</name>
        </author>
        <author>
            <name>B. Schneier</name>
        </author>
        <author>
            <name>S. M. Bellovin</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>pervasive monitoring</kw>
            <kw>privacy</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>This memo contains the thoughts and recountings of events that transpired during and after the release of information about the United States National Security Agency (NSA) by Edward Snowden in 2013.  There are four perspectives: that of someone who was involved with sifting through the information to responsibly inform the public, that of a security area director of the IETF, that of a human rights expert, and that of a computer science and affiliate law professor.  The purpose of this memo is to provide some historical perspective, while at the same time offering a view as to what security and privacy challenges the technical community should consider.  These essays do not represent a consensus view, but that of the individual authors.</p></abstract>
        <draft>draft-farrell-tenyearsafter-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9446</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9447</doc-id>
        <title>Automated Certificate Management Environment (ACME) Challenges Using an Authority Token</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>D. Hancock</name>
        </author>
        <author>
            <name>C. Wendt</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>ACME</kw>
        </keywords>
        <abstract><p>Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy.  This document specifies a generic Authority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications.</p></abstract>
        <draft>draft-ietf-acme-authority-token-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC9447</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9448</doc-id>
        <title>TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token</title>
        <author>
            <name>C. Wendt</name>
        </author>
        <author>
            <name>D. Hancock</name>
        </author>
        <author>
            <name>M. Barnes</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>STIR</kw>
        </keywords>
        <abstract><p>This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates.</p></abstract>
        <draft>draft-ietf-acme-authority-token-tnauthlist-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC9448</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9449</doc-id>
        <title>OAuth 2.0 Demonstrating Proof of Possession (DPoP)</title>
        <author>
            <name>D. Fett</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>T. Lodderstedt</name>
        </author>
        <author>
            <name>M. Jones</name>
        </author>
        <author>
            <name>D. Waite</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>security</kw>
            <kw>oauth2</kw>
        </keywords>
        <abstract><p>This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level.  This mechanism allows for the detection of replay attacks with access and refresh tokens.</p></abstract>
        <draft>draft-ietf-oauth-dpop-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9449</errata-url>
        <doi>10.17487/RFC9449</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9450</doc-id>
        <title>Reliable and Available Wireless (RAW) Use Cases</title>
        <author>
            <name>CJ. Bernardos</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Papadopoulos</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>F. Theoleyre</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>determinism</kw>
            <kw>availability</kw>
            <kw>routing</kw>
            <kw>path</kw>
        </keywords>
        <abstract><p>The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks.  At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless.  This document presents wireless use cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) control, edge robotics, and emergency vehicles), demanding reliable and available behavior.</p></abstract>
        <draft>draft-ietf-raw-use-cases-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>raw</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9450</errata-url>
        <doi>10.17487/RFC9450</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9451</doc-id>
        <title>Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH)</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>Diagnostic</kw>
            <kw>Troubelshooting</kw>
            <kw>Service Function Chaining</kw>
            <kw>Automation</kw>
            <kw>SDN</kw>
            <kw>Programmable Networks</kw>
            <kw>Service Differentiation</kw>
        </keywords>
        <abstract><p>This document clarifies an ambiguity in the Network Service Header (NSH) specification related to the handling of O bit. In particular, this document clarifies the meaning of "OAM packet".</p><p> This document updates RFC 8300.</p></abstract>
        <draft>draft-ietf-sfc-oam-packet-03</draft>
        <updates>
            <doc-id>RFC8300</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC9451</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9452</doc-id>
        <title>Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data</title>
        <author>
            <name>F. Brockners</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bhandari</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>inband</kw>
            <kw>In-situ</kw>
            <kw>Telemetry</kw>
            <kw>Tracing</kw>
        </keywords>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network.  This document outlines how IOAM-Data-Fields are encapsulated with the Network Service Header (NSH).</p></abstract>
        <draft>draft-ietf-sfc-ioam-nsh-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC9452</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9453</doc-id>
        <title>Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo)</title>
        <author>
            <name>Y. Hong</name>
        </author>
        <author>
            <name>C. Gomez</name>
        </author>
        <author>
            <name>Y. Choi</name>
        </author>
        <author>
            <name>A. Sangi</name>
        </author>
        <author>
            <name>S. Chakrabarti</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <abstract><p>This document describes the applicability of IPv6 over constrained-node networks (6lo) and provides practical deployment examples.  In addition to IEEE Std 802.15.4, various link-layer technologies are used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC).  This document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained-node networks for local or Internet connectivity.</p></abstract>
        <draft>draft-ietf-6lo-use-cases-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <doi>10.17487/RFC9453</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9454</doc-id>
        <title>Update to OSPF Terminology</title>
        <author>
            <name>M. Fox</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>OSPF terminology</kw>
        </keywords>
        <abstract><p>This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" by the US National Institute of Standards and Technology (NIST) for its inclusive language guidelines. It is intended that all future OSPF documents use this revised terminology even when they reference the RFCs updated by this document.</p><p> This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and 5838.</p></abstract>
        <draft>draft-ietf-lsr-ospf-terminology-09</draft>
        <updates>
            <doc-id>RFC2328</doc-id>
            <doc-id>RFC4222</doc-id>
            <doc-id>RFC4811</doc-id>
            <doc-id>RFC5243</doc-id>
            <doc-id>RFC5340</doc-id>
            <doc-id>RFC5614</doc-id>
            <doc-id>RFC5838</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9454</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9455</doc-id>
        <title>Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes</title>
        <author>
            <name>Z. Yan</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>G. Geng</name>
        </author>
        <author>
            <name>T. de Kock</name>
        </author>
        <author>
            <name>J. Yao</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ROA</kw>
            <kw>Route Origin Authorization</kw>
        </keywords>
        <abstract><p>When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es).  This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix.</p></abstract>
        <draft>draft-ietf-sidrops-roa-considerations-08</draft>
        <is-also>
            <doc-id>BCP0238</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9455</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9456</doc-id>
        <title>Updates to the TLS Transport Model for SNMP</title>
        <author>
            <name>K. Vaughn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>TLSTM</kw>
            <kw>DTLS</kw>
            <kw>security</kw>
            <kw>SNMPv3</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract><p>This document updates RFC 6353 ("Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)") to reflect changes necessary to support Transport Layer Security version 1.3 (TLS 1.3) and Datagram Transport Layer Security version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS.</p><p> This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.</p></abstract>
        <draft>draft-ietf-opsawg-tlstm-update-15</draft>
        <updates>
            <doc-id>RFC6353</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9456</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9457</doc-id>
        <title>Problem Details for HTTP APIs</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>E. Wilde</name>
        </author>
        <author>
            <name>S. Dalal</name>
        </author>
        <date>
            <month>July</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>status</kw>
            <kw>HTTP</kw>
            <kw>error</kw>
            <kw>problem</kw>
            <kw>API</kw>
            <kw>JSON</kw>
            <kw>XML</kw>
        </keywords>
        <abstract><p>This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.</p><p> This document obsoletes RFC 7807.</p></abstract>
        <draft>draft-ietf-httpapi-rfc7807bis-07</draft>
        <obsoletes>
            <doc-id>RFC7807</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpapi</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9457</errata-url>
        <doi>10.17487/RFC9457</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9458</doc-id>
        <title>Oblivious HTTP</title>
        <author>
            <name>M. Thomson</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>privacy</kw>
            <kw>proxy</kw>
            <kw>partitioning</kw>
            <kw>tunnel</kw>
        </keywords>
        <abstract><p>This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages.  Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.</p></abstract>
        <draft>draft-ietf-ohai-ohttp-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ohai</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9458</errata-url>
        <doi>10.17487/RFC9458</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9459</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>COSE Encryption</kw>
            <kw>Firmware encryption</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size.  CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format.  This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE.</p></abstract>
        <draft>draft-ietf-cose-aes-ctr-and-cbc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC9459</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9460</doc-id>
        <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title>
        <author>
            <name>B. Schwartz</name>
        </author>
        <author>
            <name>M. Bishop</name>
        </author>
        <author>
            <name>E. Nygren</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>multi-CDN</kw>
            <kw>HSTS</kw>
            <kw>ECH</kw>
            <kw>CNAME</kw>
            <kw>apex</kw>
            <kw>ALPN</kw>
            <kw>HTTP/3</kw>
            <kw>alias</kw>
            <kw>SvcParam</kw>
            <kw>AliasMode</kw>
            <kw>ServiceMode</kw>
        </keywords>
        <abstract><p>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins.  SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello).  They also enable aliasing of apex domains, which is not possible with CNAME.  The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics").  By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</p></abstract>
        <draft>draft-ietf-dnsop-svcb-https-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9460</errata-url>
        <doi>10.17487/RFC9460</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9461</doc-id>
        <title>Service Binding Mapping for DNS Servers</title>
        <author>
            <name>B. Schwartz</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DoH</kw>
            <kw>DoT</kw>
            <kw>DoQ</kw>
            <kw>DDR</kw>
            <kw>DNR</kw>
        </keywords>
        <abstract><p>The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service.  DNS itself can be such a service, when the server is identified by a domain name.  This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.</p></abstract>
        <draft>draft-ietf-add-svcb-dns-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>add</wg_acronym>
        <doi>10.17487/RFC9461</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9462</doc-id>
        <title>Discovery of Designated Resolvers</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>E. Kinnear</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <author>
            <name>P. McManus</name>
        </author>
        <author>
            <name>T. Jensen</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>DoH</kw>
            <kw>DoT</kw>
            <kw>DoQ</kw>
        </keywords>
        <abstract><p>This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver".  These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known.  These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities.  It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.</p></abstract>
        <draft>draft-ietf-add-ddr-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>add</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9462</errata-url>
        <doi>10.17487/RFC9462</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9463</doc-id>
        <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
        <author>
            <name>M. Boucadair</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Reddy.K</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>N. Cook</name>
        </author>
        <author>
            <name>T. Jensen</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>service resolution</kw>
            <kw>encryption</kw>
            <kw>service discovery</kw>
            <kw>service provider</kw>
            <kw>network provider</kw>
            <kw>automation</kw>
            <kw>DoH</kw>
            <kw>DoT</kw>
            <kw>DoQ</kw>
        </keywords>
        <abstract><p>This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC).  Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.</p></abstract>
        <draft>draft-ietf-add-dnr-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>add</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9463</errata-url>
        <doi>10.17487/RFC9463</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9464</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>security</kw>
            <kw>name resolution</kw>
            <kw>encryption</kw>
            <kw>service discovery</kw>
            <kw>naming</kw>
            <kw>resolver</kw>
            <kw>stub-resolver</kw>
            <kw>CPE</kw>
            <kw>Customer premise equipment</kw>
            <kw>VPN</kw>
            <kw>Secure discovery</kw>
            <kw>DoT</kw>
            <kw>DoH</kw>
            <kw>DoQ</kw>
            <kw>Tunnel</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract><p>This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ).</p></abstract>
        <draft>draft-ietf-ipsecme-add-ike-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9464</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9465</doc-id>
        <title>PIM Null-Register Packing</title>
        <author>
            <name>V. Kamath</name>
        </author>
        <author>
            <name>R. Chokkanathapuram Sundaram</name>
        </author>
        <author>
            <name>R. Banthia</name>
        </author>
        <author>
            <name>A. Gopal</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Multicast</kw>
        </keywords>
        <abstract><p>In PIM Sparse Mode (PIM-SM) networks, PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single multicast source and group.</p><p> This document defines a standard to send information about multiple multicast sources and groups in a single PIM message. This document refers to the new messages as the "PIM Packed Null-Register message" and "PIM Packed Register-Stop message".</p></abstract>
        <draft>draft-ietf-pim-null-register-packing-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9465</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9466</doc-id>
        <title>PIM Assert Message Packing</title>
        <author>
            <name>Y. Liu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Eckert</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. McBride</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>When PIM Sparse Mode (PIM-SM), including PIM Source-Specific Multicast (PIM-SSM), is used in shared LAN networks, there is often more than one upstream router. This can lead to duplicate IP multicast packets being forwarded by these PIM routers. PIM Assert messages are used to elect a single forwarder for each IP multicast traffic flow between these routers.</p><p> This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. This optimization reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets incurred.</p></abstract>
        <draft>draft-ietf-pim-assert-packing-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9466</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9467</doc-id>
        <title>Relaxed Packet Counter Verification for Babel MAC Authentication</title>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <author>
            <name>T. Høiland-Jørgensen</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>wi-fi</kw>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>packet reordering</kw>
            <kw>wifi</kw>
        </keywords>
        <abstract><p>This document relaxes the packet verification rules defined in "MAC Authentication for the Babel Routing Protocol" (RFC 8967) in order to make the protocol more robust in the presence of packet reordering.  This document updates RFC 8967.</p></abstract>
        <draft>draft-ietf-babel-mac-relaxed-05</draft>
        <updates>
            <doc-id>RFC8967</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC9467</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9468</doc-id>
        <title>Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>R. Raszuk</name>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <date>
            <month>August</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>For operational simplification of "sessionless" applications using Bidirectional Forwarding Detection (BFD), in this document, we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side and established without explicit per-session configuration or registration by the other side (subject to certain per-interface or global policies).</p><p> We also introduce a new YANG module to configure and manage "unsolicited BFD". The YANG module in this document is based on YANG 1.1, as defined in RFC 7950, and conforms to the Network Management Datastore Architecture (NMDA), as described in RFC 8342. This document augments RFC 9314.</p></abstract>
        <draft>draft-ietf-bfd-unsolicited-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC9468</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9469</doc-id>
        <title>Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>EVPN</kw>
            <kw>Applicability</kw>
            <kw>NVO3</kw>
        </keywords>
        <abstract><p>An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by Network Virtualization over Layer 3 (NVO3) networks.  EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlay IP Fabric, i.e., there is no need to enable Protocol Independent Multicast (PIM) in the underlay network and maintain multicast states for tenant Broadcast Domains.  This document describes the use of EVPN for NVO3 networks and discusses its applicability to basic Layer 2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming, Data Center Interconnect (DCI), and much more.  No new EVPN procedures are introduced.</p></abstract>
        <draft>draft-ietf-nvo3-evpn-applicability-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC9469</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9470</doc-id>
        <title>OAuth 2.0 Step Up Authentication Challenge Protocol</title>
        <author>
            <name>V. Bertocci</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>security</kw>
            <kw>oauth2</kw>
            <kw>openid connect</kw>
            <kw>oauth</kw>
            <kw>step-up</kw>
        </keywords>
        <abstract><p>It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request.  This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them.  This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request.</p></abstract>
        <draft>draft-ietf-oauth-step-up-authn-challenge-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9470</errata-url>
        <doi>10.17487/RFC9470</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9471</doc-id>
        <title>DNS Glue Requirements in Referral Responses</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <author>
            <name>S. Huque</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>Glue Record</kw>
            <kw>In-Domain Name Server</kw>
            <kw>Sibling Domain Name Server</kw>
        </keywords>
        <abstract><p>The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone.  Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response.  If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior.</p></abstract>
        <draft>draft-ietf-dnsop-glue-is-not-optional-09</draft>
        <updates>
            <doc-id>RFC1034</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9471</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9472</doc-id>
        <title>A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>To improve cybersecurity posture, automation is necessary to locate the software a device is using, whether that software has known vulnerabilities, and what, if any, recommendations suppliers may have.  This memo extends the Manufacturer User Description (MUD) YANG schema to provide the locations of software bills of materials (SBOMs) and vulnerability information by introducing a transparency schema.</p></abstract>
        <draft>draft-ietf-opsawg-sbom-access-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9472</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9473</doc-id>
        <title>A Vocabulary of Path Properties</title>
        <author>
            <name>R. Enghardt</name>
        </author>
        <author>
            <name>C. Krähenbühl</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PAN</kw>
            <kw>path-aware network</kw>
            <kw>path property</kw>
            <kw>path selection</kw>
        </keywords>
        <abstract><p>Path properties express information about paths across a network and the services provided via such paths.  In a path-aware network, path properties may be fully or partially available to entities such as endpoints.  This document defines and categorizes path properties.  Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services.  This document is a product of the Path Aware Networking Research Group (PANRG).</p></abstract>
        <draft>draft-irtf-panrg-path-properties-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9473</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9474</doc-id>
        <title>RSA Blind Signatures</title>
        <author>
            <name>F. Denis</name>
        </author>
        <author>
            <name>F. Jacobs</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>RSABSSA</kw>
            <kw>RSA</kw>
            <kw>blind signature</kw>
        </keywords>
        <abstract><p>This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-rsa-blind-signatures-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9474</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9475</doc-id>
        <title>Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>C. Wendt</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>SIP</kw>
        </keywords>
        <abstract><p>Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling.  Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space.  This document explores the applicability of STIR's Personal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP.</p></abstract>
        <draft>draft-ietf-stir-messaging-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC9475</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9476</doc-id>
        <title>The .alt Special-Use Top-Level Domain</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts.  It also provides advice and guidance to developers creating alternative namespaces.</p></abstract>
        <draft>draft-ietf-dnsop-alt-tld-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9476</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9477</doc-id>
        <title>Complaint Feedback Loop Address Header</title>
        <author>
            <name>J. Benecke</name>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a CFBL. Currently, providing and maintaining such an address is a manual and time-consuming process for Message Originators and Mailbox Providers.</p><p> The mechanism specified in this document is being published as an experiment to gather feedback and gauge the interest of implementers and deployers. This document is produced through the Independent RFC Stream and was not subject to the IETF's approval process.</p></abstract>
        <draft>draft-benecke-cfbl-address-header-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9477</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9478</doc-id>
        <title>Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>P. Wouters</name>
        </author>
        <author>
            <name>S. Prasad</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IKEv2</kw>
            <kw>SPD</kw>
            <kw>SAD</kw>
        </keywords>
        <abstract><p>This document defines a new Traffic Selector Type (TS Type) for the Internet Key Exchange Protocol version 2 (IKEv2) to add support for negotiating Mandatory Access Control (MAC) security labels as a Traffic Selector of the Security Policy Database (SPD).  Security Labels for IPsec are also known as "Labeled IPsec".  The new TS Type, TS_SECLABEL, consists of a variable length opaque field that specifies the security label.</p></abstract>
        <draft>draft-ietf-ipsecme-labeled-ipsec-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9478</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9479</doc-id>
        <title>IS-IS Application-Specific Link Attributes</title>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings.</p><p> This document obsoletes RFC 8919.</p></abstract>
        <draft>draft-ietf-lsr-rfc8919bis-04</draft>
        <obsoletes>
            <doc-id>RFC8919</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9479</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9480</doc-id>
        <title>Certificate Management Protocol (CMP) Updates</title>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <author>
            <name>D. von Oheimb</name>
        </author>
        <author>
            <name>J. Gray</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>55</page-count>
        <keywords>
            <kw>CMP</kw>
        </keywords>
        <abstract><p>This document contains a set of updates to the syntax of Certificate Management Protocol (CMP) version 2 and its HTTP transfer mechanism. This document updates RFCs 4210, 5912, and 6712.</p><p> The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.</p><p> CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed.</p></abstract>
        <draft>draft-ietf-lamps-cmp-updates-23</draft>
        <obsoleted-by>
            <doc-id>RFC9810</doc-id>
            <doc-id>RFC9811</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC4210</doc-id>
            <doc-id>RFC5912</doc-id>
            <doc-id>RFC6712</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9480</errata-url>
        <doi>10.17487/RFC9480</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9481</doc-id>
        <title>Certificate Management Protocol (CMP) Algorithms</title>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <author>
            <name>H. Aschauer</name>
        </author>
        <author>
            <name>M. Ounsworth</name>
        </author>
        <author>
            <name>J. Gray</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document describes the conventions for using several
cryptographic algorithms with the Certificate Management Protocol
(CMP).  CMP is used to enroll and further manage the lifecycle of
X.509 certificates.  This document also updates the algorithm use
profile from Appendix D.2 of RFC 4210.</p></abstract>
        <draft>draft-ietf-lamps-cmp-algorithms-15</draft>
        <updates>
            <doc-id>RFC4210</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9481</errata-url>
        <doi>10.17487/RFC9481</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9482</doc-id>
        <title>Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol</title>
        <author>
            <name>M. Sahni</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Tripathi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies the use of the Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP).  CMP defines the interaction between various PKI entities for the purpose of certificate creation and management.  CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space.</p></abstract>
        <draft>draft-ietf-ace-cmpv2-coap-transport-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9482</errata-url>
        <doi>10.17487/RFC9482</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9483</doc-id>
        <title>Lightweight Certificate Management Protocol (CMP) Profile</title>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <author>
            <name>D. von Oheimb</name>
        </author>
        <author>
            <name>S. Fries</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>83</page-count>
        <abstract><p>This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios.  This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way.  To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory.  More specialized or complex use cases are supported with optional features.</p></abstract>
        <draft>draft-ietf-lamps-lightweight-cmp-profile-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9483</errata-url>
        <doi>10.17487/RFC9483</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9484</doc-id>
        <title>Proxying IP in HTTP</title>
        <author>
            <name>T. Pauly</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>A. Chernyakhovsky</name>
        </author>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>quic</kw>
            <kw>http</kw>
            <kw>datagram</kw>
            <kw>VPN</kw>
            <kw>proxy</kw>
            <kw>tunnels</kw>
            <kw>quic in udp in IP in quic</kw>
            <kw>turtles all the way down</kw>
            <kw>masque</kw>
            <kw>http-ng</kw>
        </keywords>
        <abstract><p>This document describes how to proxy IP packets in HTTP.  This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy.  This document updates RFC 9298.</p></abstract>
        <draft>draft-ietf-masque-connect-ip-13</draft>
        <updates>
            <doc-id>RFC9298</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>masque</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9484</errata-url>
        <doi>10.17487/RFC9484</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9485</doc-id>
        <title>I-Regexp: An Interoperable Regular Expression Format</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>T. Bray</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Regexp</kw>
            <kw>Regex</kw>
        </keywords>
        <abstract><p>This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries.</p></abstract>
        <draft>draft-ietf-jsonpath-iregexp-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jsonpath</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9485</errata-url>
        <doi>10.17487/RFC9485</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9486</doc-id>
        <title>IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)</title>
        <author>
            <name>S. Bhandari</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Brockners</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network.  This document outlines how IOAM Data-Fields are encapsulated in IPv6.</p></abstract>
        <draft>draft-ietf-ippm-ioam-ipv6-options-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9486</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9487</doc-id>
        <title>Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)</title>
        <author>
            <name>T. Graf</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>P. Francois</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>SRv6</kw>
            <kw>SR</kw>
            <kw>Flow Record</kw>
        </keywords>
        <abstract><p>This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with.</p></abstract>
        <draft>draft-ietf-opsawg-ipfix-srv6-srh-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9487</errata-url>
        <doi>10.17487/RFC9487</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9488</doc-id>
        <title>Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP)</title>
        <author>
            <name>A. Stone</name>
        </author>
        <author>
            <name>M. Aissaoui</name>
        </author>
        <author>
            <name>S. Sidor</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>segment routing</kw>
            <kw>adjacency sid</kw>
            <kw>sla</kw>
            <kw>fast reroute</kw>
            <kw>ti-lfa</kw>
        </keywords>
        <abstract><p>This document updates RFC 5440 to clarify usage of the Local Protection Desired bit signaled in the Path Computation Element Communication Protocol (PCEP).  This document also introduces a new flag for signaling protection enforcement in PCEP.</p></abstract>
        <draft>draft-ietf-pce-local-protection-enforcement-11</draft>
        <updates>
            <doc-id>RFC5440</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9488</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9489</doc-id>
        <title>Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN)</title>
        <author>
            <name>P. Jain</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>S. Salam</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>EVPN</kw>
            <kw>LSP Ping</kw>
            <kw>MPLS OAM</kw>
        </keywords>
        <abstract><p>Label Switched Path (LSP) Ping is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in MPLS networks.  This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS-based Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) networks.</p></abstract>
        <draft>draft-ietf-bess-evpn-lsp-ping-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9489</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9490</doc-id>
        <title>Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)</title>
        <author>
            <name>M. Knodel</name>
        </author>
        <author>
            <name>W. Hardaker</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>network management</kw>
        </keywords>
        <abstract><p>The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the expressed during the workshop by participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-m-ten-workshop-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9490</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9491</doc-id>
        <title>Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)</title>
        <author>
            <name>J. Guichard</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Tantsura</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>NSH</kw>
            <kw>SR</kw>
            <kw>MPLS-SR</kw>
            <kw>SRv6</kw>
            <kw>SFC</kw>
        </keywords>
        <abstract><p>This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.</p><p> Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a given Service Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.</p><p> This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH.</p></abstract>
        <draft>draft-ietf-spring-nsh-sr-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9491</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9492</doc-id>
        <title>OSPF Application-Specific Link Attributes</title>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications such as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.</p><p> This document obsoletes RFC 8920.</p></abstract>
        <draft>draft-ietf-lsr-rfc8920bis-06</draft>
        <obsoletes>
            <doc-id>RFC8920</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9492</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9493</doc-id>
        <title>Subject Identifiers for Security Event Tokens</title>
        <author>
            <name>A. Backman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Scurtescu</name>
        </author>
        <author>
            <name>P. Jain</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>jwt</kw>
        </keywords>
        <abstract><p>Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event.  This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects.  It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT) "sub_id" Claim.</p></abstract>
        <draft>draft-ietf-secevent-subject-identifiers-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>secevent</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9493</errata-url>
        <doi>10.17487/RFC9493</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9494</doc-id>
        <title>Long-Lived Graceful Restart for BGP</title>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document introduces a BGP capability called the "Long-Lived Graceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP Graceful Restart (as described in RFC 4724). A well-known BGP community called "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called "NO_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is.</p><p> This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers.</p></abstract>
        <draft>draft-ietf-idr-long-lived-gr-06</draft>
        <updates>
            <doc-id>RFC6368</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9494</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9495</doc-id>
        <title>Certification Authority Authorization (CAA) Processing for Email Addresses</title>
        <author>
            <name>C. Bonnell</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>caa</kw>
            <kw>certification authority authorization</kw>
            <kw>email address</kw>
        </keywords>
        <abstract><p>The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities that are authorized to issue certificates for the domain.  RFC 8659 contains the core CAA specification, where Property Tags that restrict the issuance of certificates that certify domain names are defined.  This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension.</p></abstract>
        <draft>draft-ietf-lamps-caa-issuemail-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9495</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9496</doc-id>
        <title>The ristretto255 and decaf448 Groups</title>
        <author>
            <name>H. de Valence</name>
        </author>
        <author>
            <name>J. Grigg</name>
        </author>
        <author>
            <name>M. Hamburg</name>
        </author>
        <author>
            <name>I. Lovecruft</name>
        </author>
        <author>
            <name>G. Tankersley</name>
        </author>
        <author>
            <name>F. Valsorda</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>cryptographic group</kw>
            <kw>cryptography</kw>
            <kw>Curve25519</kw>
            <kw>ecc</kw>
            <kw>edwards448</kw>
            <kw>elliptic curve</kw>
            <kw>elliptic curve cryptography</kw>
            <kw>nonmalleable encodings</kw>
            <kw>prime-order</kw>
            <kw>prime order</kw>
        </keywords>
        <abstract><p>This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448.</p><p> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-ristretto255-decaf448-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9496</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9497</doc-id>
        <title>Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups</title>
        <author>
            <name>A. Davidson</name>
        </author>
        <author>
            <name>A. Faz-Hernandez</name>
        </author>
        <author>
            <name>N. Sullivan</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>61</page-count>
        <abstract><p>An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF).  The server provides the PRF private key, and the client provides the PRF input.  At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output.  An OPRF can also satisfy a notion of 'verifiability', called a VOPRF.  A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol.  A VOPRF can also be partially oblivious, called a POPRF.  A POPRF allows clients and servers to provide public input to the PRF computation.  This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves.  This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-voprf-21</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9497</errata-url>
        <doi>10.17487/RFC9497</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9498</doc-id>
        <title>The GNU Name System</title>
        <author>
            <name>M. Schanzenbach</name>
        </author>
        <author>
            <name>C. Grothoff</name>
        </author>
        <author>
            <name>B. Fix</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>74</page-count>
        <keywords>
            <kw>name systems</kw>
        </keywords>
        <abstract><p>This document provides the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols.</p><p> This document defines the normative wire format of resource records, resolution processes, cryptographic routines, and security and privacy considerations for use by implementers.</p><p> This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations (for example, pre-existing GNUnet implementations).</p></abstract>
        <draft>draft-schanzen-gns-28</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9498</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9499</doc-id>
        <title>DNS Terminology</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>vocabulary</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract><p>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</p><p> This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</p></abstract>
        <draft>draft-ietf-dnsop-rfc8499bis-10</draft>
        <obsoletes>
            <doc-id>RFC8499</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2308</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0219</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9499</errata-url>
        <doi>10.17487/RFC9499</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9500</doc-id>
        <title>Standard Public Key Cryptography (PKC) Test Keys</title>
        <author>
            <name>P. Gutmann</name>
        </author>
        <author>
            <name>C. Bonnell</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <abstract><p>This document provides a set of standard Public Key Cryptography (PKC) test keys that may be used wherever pre-generated keys and associated operations like digital signatures are required.  Like the European Institute for Computer Antivirus Research (EICAR) virus test and the Generic Test for Unsolicited Bulk Email (GTUBE) spam test files, these publicly known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them.</p></abstract>
        <draft>draft-gutmann-testkeys-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9500</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9501</doc-id>
        <title>Open Participation Principle regarding Remote Registration Fee</title>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>J. Reed</name>
        </author>
        <author>
            <name>R. Salz</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>no-cost</kw>
            <kw>meetings</kw>
            <kw>remote participation fee</kw>
            <kw>remote</kw>
        </keywords>
        <abstract><p>This document outlines a principle for open participation that
extends the open process principle defined in RFC 3935 by stating
that there must be a free option for online participation to IETF
meetings and, if possible, related IETF-hosted events.</p></abstract>
        <draft>draft-ietf-shmoo-remote-fee-09</draft>
        <is-also>
            <doc-id>BCP0239</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>gen</area>
        <wg_acronym>shmoo</wg_acronym>
        <doi>10.17487/RFC9501</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9502</doc-id>
        <title>IGP Flexible Algorithm in IP Networks</title>
        <author>
            <name>W. Britto</name>
        </author>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>P. Kaneriya</name>
        </author>
        <author>
            <name>R. Shetty</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IS-IS</kw>
        </keywords>
        <abstract><p>This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding.</p></abstract>
        <draft>draft-ietf-lsr-ip-flexalgo-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9502</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9503</doc-id>
        <title>Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks</title>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>B. Janssens</name>
        </author>
        <author>
            <name>R. Foote</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>Segment Routing (SR) leverages the source routing paradigm.  SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes.  This document specifies Simple Two-Way Active Measurement Protocol (STAMP) extensions (as described in RFC 8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972.</p></abstract>
        <draft>draft-ietf-ippm-stamp-srpm-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9503</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9504</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks</title>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>O. Gonzalez de Dios</name>
        </author>
        <author>
            <name>V. Lopez</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Stateful PCE</kw>
            <kw>GMPLS</kw>
            <kw>PCE-initiated LSP</kw>
        </keywords>
        <abstract><p>The Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE functions where the stateful PCE maintains information about paths and resource usage within a network; however, these extensions do not cover all requirements for GMPLS networks.</p><p> This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks.</p></abstract>
        <draft>draft-ietf-pce-pcep-stateful-pce-gmpls-23</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9504</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9505</doc-id>
        <title>A Survey of Worldwide Censorship Techniques</title>
        <author>
            <name>J. L. Hall</name>
        </author>
        <author>
            <name>M. D. Aaron</name>
        </author>
        <author>
            <name>A. Andersdotter</name>
        </author>
        <author>
            <name>B. Jones</name>
        </author>
        <author>
            <name>N. Feamster</name>
        </author>
        <author>
            <name>M. Knodel</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>34</page-count>
        <keywords>
            <kw>network censorship</kw>
            <kw>network blocking</kw>
            <kw>network throttling</kw>
            <kw>traffic impairment</kw>
            <kw>censorship circumvention</kw>
        </keywords>
        <abstract><p>This document describes technical mechanisms employed in network censorship that regimes around the world use for blocking or impairing Internet traffic.  It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information.  This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference.  This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF.</p></abstract>
        <draft>draft-irtf-pearg-censorship-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9505</errata-url>
        <doi>10.17487/RFC9505</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9506</doc-id>
        <title>Explicit Host-to-Network Flow Measurements Techniques</title>
        <author>
            <name>M. Cociglio</name>
        </author>
        <author>
            <name>A. Ferrieux</name>
        </author>
        <author>
            <name>G. Fioccola</name>
        </author>
        <author>
            <name>I. Lubashev</name>
        </author>
        <author>
            <name>F. Bulgarella</name>
        </author>
        <author>
            <name>M. Nilo</name>
        </author>
        <author>
            <name>I. Hamchaoui</name>
        </author>
        <author>
            <name>R. Sisto</name>
        </author>
        <date>
            <month>October</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>Performance</kw>
            <kw>Monitoring</kw>
            <kw>Passive</kw>
            <kw>Hybrid</kw>
            <kw>Loss</kw>
            <kw>Delay</kw>
            <kw>Client</kw>
            <kw>Server</kw>
            <kw>On-path</kw>
            <kw>Observer</kw>
            <kw>Probe</kw>
            <kw>Alternate</kw>
            <kw>Marking</kw>
            <kw>Round</kw>
            <kw>Trip</kw>
            <kw>Latency</kw>
            <kw>Encrypted</kw>
            <kw>Protocol</kw>
            <kw>Bits</kw>
        </keywords>
        <abstract><p>This document describes protocol-independent methods called Explicit Host-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server.  These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate.  Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection.  The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices.  This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied.</p></abstract>
        <draft>draft-ietf-ippm-explicit-flow-measurements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9506</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9507</doc-id>
        <title>Information-Centric Networking (ICN) Traceroute Protocol Specification</title>
        <author>
            <name>S. Mastorakis</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>I. Moiseenko</name>
        </author>
        <author>
            <name>J. Gibson</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>ICN</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract><p>This document presents the design of an Information-Centric Networking (ICN) Traceroute protocol. This includes the operation of both the client and the forwarder.</p><p> This document is a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF.</p></abstract>
        <draft>draft-irtf-icnrg-icntraceroute-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9507</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9508</doc-id>
        <title>Information-Centric Networking (ICN) Ping Protocol Specification</title>
        <author>
            <name>S. Mastorakis</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>J. Gibson</name>
        </author>
        <author>
            <name>I. Moiseenko</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>ICN</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract><p>This document presents the design of an Information-Centric Networking (ICN) Ping protocol. It includes the operations of both the client and the forwarder.</p><p> This document is a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF.</p></abstract>
        <draft>draft-irtf-icnrg-icnping-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9508</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9509</doc-id>
        <title>X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions</title>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>J. Ekman</name>
        </author>
        <author>
            <name>D. Migault</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>3GPP</kw>
        </keywords>
        <abstract><p>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens (JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by Network Functions (NFs) for the 5G System.</p></abstract>
        <draft>draft-ietf-lamps-nf-eku-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9509</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9510</doc-id>
        <title>Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic</title>
        <author>
            <name>C. Gündoğan</name>
        </author>
        <author>
            <name>T. Schmidt</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>M. Wählisch</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>CCNx</kw>
            <kw>constrained networks</kw>
            <kw>compressed delta time</kw>
            <kw>IoT</kw>
        </keywords>
        <abstract><p>Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.</p><p> This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</p></abstract>
        <draft>draft-irtf-icnrg-ccnx-timetlv-05</draft>
        <updates>
            <doc-id>RFC8609</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9510</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9511</doc-id>
        <title>Attribution of Internet Probes</title>
        <author>
            <name>É. Vyncke</name>
        </author>
        <author>
            <name>B. Donnet</name>
        </author>
        <author>
            <name>J. Iurman</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>Active measurements over the public Internet can target either collaborating parties or non-collaborating ones. Sometimes these measurements, also called "probes", are viewed as unwelcome or aggressive.</p><p> This document suggests some simple techniques for a source to identify its probes. This allows any party or organization to understand what an unsolicited probe packet is, what its purpose is, and, most importantly, who to contact. The technique relies on offline analysis of the probe; therefore, it does not require any change in the data or control plane. It has been designed mainly for layer 3 measurements.</p></abstract>
        <draft>draft-ietf-opsec-probe-attribution-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsec</wg_acronym>
        <doi>10.17487/RFC9511</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9512</doc-id>
        <title>YAML Media Type</title>
        <author>
            <name>R. Polli</name>
        </author>
        <author>
            <name>E. Wilde</name>
        </author>
        <author>
            <name>E. Aro</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>data interchange format</kw>
        </keywords>
        <abstract><p>This document registers the application/yaml media type and the +yaml structured syntax suffix with IANA.  Both identify document components that are serialized according to the YAML specification.</p></abstract>
        <draft>draft-ietf-httpapi-yaml-mediatypes-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpapi</wg_acronym>
        <doi>10.17487/RFC9512</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9513</doc-id>
        <title>OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>Z. Hu</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>OSPF</kw>
            <kw>OSPFv3</kw>
            <kw>Segment Routing</kw>
            <kw>SRv6</kw>
        </keywords>
        <abstract><p>The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments.  It can be implemented over an MPLS or IPv6 data plane.  This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane.</p></abstract>
        <draft>draft-ietf-lsr-ospfv3-srv6-extensions-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9513</errata-url>
        <doi>10.17487/RFC9513</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9514</doc-id>
        <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)</title>
        <author>
            <name>G. Dawra</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>D. Bernier</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>BGP-LS</kw>
            <kw>Segment Routing</kw>
            <kw>SRv6</kw>
        </keywords>
        <abstract><p>Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3.</p><p> This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085.</p></abstract>
        <draft>draft-ietf-idr-bgpls-srv6-ext-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9514</errata-url>
        <doi>10.17487/RFC9514</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9515</doc-id>
        <title>Revision to Registration Procedures for Multiple BMP Registries</title>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>3</page-count>
        <keywords>
            <kw>IDR</kw>
        </keywords>
        <abstract><p>This document updates RFC 7854, "BGP Monitoring Protocol (BMP)", by changing the registration procedures for several registries.  Specifically, any BMP registry with a range of 32768-65530 designated "Specification Required" has that range redesignated as "First Come First Served".</p></abstract>
        <draft>draft-ietf-grow-bmp-registries-change-04</draft>
        <updates>
            <doc-id>RFC7854</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC9515</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9516</doc-id>
        <title>Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>W. Meng</name>
        </author>
        <author>
            <name>T. Ao</name>
        </author>
        <author>
            <name>B. Khasnabish</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <author>
            <name>G. Mishra</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <abstract><p>A set of requirements for active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC) in a network is presented in this document.  Based on these requirements, an encapsulation of active OAM messages in SFC and a mechanism to detect and localize defects are described.</p></abstract>
        <draft>draft-ietf-sfc-multi-layer-oam-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>sfc</wg_acronym>
        <doi>10.17487/RFC9516</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9517</doc-id>
        <title>A URN Namespace for the Data Documentation Initiative (DDI)</title>
        <author>
            <name>J. Wackerow</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>This document describes the Namespace Identifier (NID) "ddi" for Uniform Resource Names (URNs) used to identify resources that conform to the standards published by the Data Documentation Initiative (DDI) Alliance.</p><p> The DDI Alliance is not affiliated with the Internet Engineering Task Force (IETF) or Internet Society (ISOC). This Independent Submission is not a standard nor does it have IETF community consensus.</p></abstract>
        <draft>draft-urn-ddi-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9517</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9518</doc-id>
        <title>Centralization, Decentralization, and Internet Standards</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>governance</kw>
        </keywords>
        <abstract><p>This document discusses aspects of centralization that relate to Internet standards efforts.  It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet.</p></abstract>
        <draft>draft-nottingham-avoiding-internet-centralization-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9518</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9519</doc-id>
        <title>Update to the IANA SSH Protocol Parameters Registry Requirements</title>
        <author>
            <name>P. Yee</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>ssh</kw>
            <kw>iana</kw>
            <kw>registry</kw>
        </keywords>
        <abstract><p>This specification updates the registration policies for adding new entries to registries within the IANA "Secure Shell (SSH) Protocol Parameters" group of registries.  Previously, the registration policy was generally IETF Review, as defined in RFC 8126, although a few registries require Standards Action.  This specification changes it from IETF Review to Expert Review.  This document updates RFCs 4250, 4716, 4819, and 8308.</p></abstract>
        <draft>draft-yee-ssh-iana-requirements-03</draft>
        <updates>
            <doc-id>RFC4250</doc-id>
            <doc-id>RFC4716</doc-id>
            <doc-id>RFC4819</doc-id>
            <doc-id>RFC8308</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9519</errata-url>
        <doi>10.17487/RFC9519</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9520</doc-id>
        <title>Negative Caching of DNS Resolution Failures</title>
        <author>
            <name>D. Wessels</name>
        </author>
        <author>
            <name>W. Carroll</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Negative</kw>
            <kw>Caching</kw>
        </keywords>
        <abstract><p>In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data, (2) a response indicating the requested data does not exist, or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.</p><p> RFC 2308 specifies requirements for DNS negative caching. There, caching of TYPE 2 responses is mandatory and caching of TYPE 3 responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures.</p><p> RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures.</p><p> RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones.</p></abstract>
        <draft>draft-ietf-dnsop-caching-resolution-failures-08</draft>
        <updates>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC4035</doc-id>
            <doc-id>RFC4697</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9520</errata-url>
        <doi>10.17487/RFC9520</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9521</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for  Generic Network Virtualization Encapsulation (Geneve)</title>
        <author>
            <name>X. Min</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>S. Pallagatti</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>S. Aldrin</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>NVE</kw>
            <kw>VAP</kw>
            <kw>VNI</kw>
        </keywords>
        <abstract><p>This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network.</p></abstract>
        <draft>draft-ietf-nvo3-bfd-geneve-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC9521</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9522</doc-id>
        <title>Overview and Principles of Internet Traffic Engineering</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>73</page-count>
        <abstract><p>This document 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 the networks that support IP networking 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 networks are also discussed.</p><p> This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF.</p></abstract>
        <draft>draft-ietf-teas-rfc3272bis-27</draft>
        <obsoletes>
            <doc-id>RFC3272</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9522</errata-url>
        <doi>10.17487/RFC9522</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9523</doc-id>
        <title>A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos</title>
        <author>
            <name>N. Rozen-Schiff</name>
        </author>
        <author>
            <name>D. Dolev</name>
        </author>
        <author>
            <name>T. Mizrahi</name>
        </author>
        <author>
            <name>M. Schapira</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>NTPv4</kw>
        </keywords>
        <abstract><p>The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet.  This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time-shifting attacks.  Khronos involves changes to the NTP client's system process only.  Since it does not affect the wire protocol, the Khronos mechanism is applicable to current and future time protocols.</p></abstract>
        <draft>draft-ietf-ntp-chronos-25</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC9523</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9524</doc-id>
        <title>Segment Routing Replication for Multipoint Service Delivery</title>
        <author>
            <name>D. Voyer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>R. Parekh</name>
        </author>
        <author>
            <name>H. Bidgoli</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <abstract><p>This document describes the Segment Routing Replication segment for multipoint service delivery.  A Replication segment allows a packet to be replicated from a replication node to downstream nodes.</p></abstract>
        <draft>draft-ietf-spring-sr-replication-segment-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9524</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9525</doc-id>
        <title>Service Identity in TLS</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <author>
            <name>R. Salz</name>
        </author>
        <date>
            <month>November</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.</p><p> This document obsoletes RFC 6125.</p></abstract>
        <draft>draft-ietf-uta-rfc6125bis-15</draft>
        <obsoletes>
            <doc-id>RFC6125</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9525</errata-url>
        <doi>10.17487/RFC9525</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9526</doc-id>
        <title>Simple Provisioning of Public Names for Residential Networks</title>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>R. Weber</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>R. Hunter</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Homenet</kw>
            <kw>outsourcing</kw>
            <kw>management</kw>
            <kw>hosting</kw>
        </keywords>
        <abstract><p>Home network owners may have devices or services hosted on their home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which in principle makes this access simpler, but accessing home networks from the Internet requires the names and IP addresses of these devices and services to be made available in the public DNS.</p><p> This document describes how a Home Naming Authority (NHA) instructs the outsourced infrastructure to publish these pieces of information in the public DNS. The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs an outsourced infrastructure to publish the zone on behalf of the home network owner.</p></abstract>
        <draft>draft-ietf-homenet-front-end-naming-delegation-27</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9526</errata-url>
        <doi>10.17487/RFC9526</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9527</doc-id>
        <title>DHCPv6 Options for the Homenet Naming Authority</title>
        <author>
            <name>D. Migault</name>
        </author>
        <author>
            <name>R. Weber</name>
        </author>
        <author>
            <name>T. Mrugalski</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document defines DHCPv6 options so that a Homenet Naming Authority (HNA) can automatically set the appropriate configuration and outsource the authoritative naming service for the home network.  In most cases, the outsourcing mechanism is transparent for the end user.</p></abstract>
        <draft>draft-ietf-homenet-naming-architecture-dhc-options-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>homenet</wg_acronym>
        <doi>10.17487/RFC9527</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9528</doc-id>
        <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>F. Palombini</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>82</page-count>
        <keywords>
            <kw>AKE</kw>
            <kw>LAKE</kw>
            <kw>COSE</kw>
            <kw>OSCORE</kw>
            <kw>lightweight authenticated key exchange</kw>
            <kw>constrained node networks</kw>
            <kw>IoT security</kw>
        </keywords>
        <abstract><p>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys.  EDHOC provides mutual authentication, forward secrecy, and identity protection.  EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context.  By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.</p></abstract>
        <draft>draft-ietf-lake-edhoc-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lake</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9528</errata-url>
        <doi>10.17487/RFC9528</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9529</doc-id>
        <title>Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
        <author>
            <name>G. Selander</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <author>
            <name>M. Serafin</name>
        </author>
        <author>
            <name>M. Tiloca</name>
        </author>
        <author>
            <name>M. Vučinić</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>test vector</kw>
            <kw>lightweight</kw>
            <kw>authenticated key exchange</kw>
            <kw>LAKE</kw>
            <kw>AKE</kw>
        </keywords>
        <abstract><p>This document contains example traces of Ephemeral Diffie-Hellman Over COSE (EDHOC).</p></abstract>
        <draft>draft-ietf-lake-traces-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lake</wg_acronym>
        <doi>10.17487/RFC9529</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9530</doc-id>
        <title>Digest Fields</title>
        <author>
            <name>R. Polli</name>
        </author>
        <author>
            <name>L. Pardue</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>Digest</kw>
        </keywords>
        <abstract><p>This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.</p><p> This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.</p></abstract>
        <draft>draft-ietf-httpbis-digest-headers-13</draft>
        <obsoletes>
            <doc-id>RFC3230</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9530</errata-url>
        <doi>10.17487/RFC9530</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9531</doc-id>
        <title>Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)</title>
        <author>
            <name>I. Moiseenko</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>ICN</kw>
        </keywords>
        <abstract><p>Path steering is a mechanism to discover paths to the producers of Information-Centric Networking (ICN) Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi-path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in "Path Switching in Content Centric and Named Data Networks" (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.</p><p> This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). It is not an IETF product and is not an Internet Standard.</p></abstract>
        <draft>draft-irtf-icnrg-pathsteering-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9531</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9532</doc-id>
        <title>HTTP Proxy-Status Parameter for Next-Hop Aliases</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>proxy status</kw>
        </keywords>
        <abstract><p>This document defines the next-hop-aliases HTTP Proxy-Status Parameter.  This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part of establishing a connection to the next hop.</p></abstract>
        <draft>draft-ietf-httpbis-alias-proxy-status-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9532</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9533</doc-id>
        <title>One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <author>
            <name>J. Guo</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>R. Gandhi</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>TWAMP</kw>
            <kw>OWAMP</kw>
            <kw>Performance Measurement</kw>
            <kw>LAG</kw>
            <kw>Micro-session</kw>
        </keywords>
        <abstract><p>This document defines extensions to the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG).  Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance-based traffic steering policy across the member links.</p></abstract>
        <draft>draft-ietf-ippm-otwamp-on-lag-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9533</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9534</doc-id>
        <title>Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <author>
            <name>J. Guo</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>R. Gandhi</name>
        </author>
        <date>
            <month>January</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>STAMP</kw>
            <kw>Performance Measurement</kw>
            <kw>LAG</kw>
            <kw>Micro Session</kw>
        </keywords>
        <abstract><p>This document extends Simple Two-way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG).  Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance-based traffic steering policy across the member links.</p></abstract>
        <draft>draft-ietf-ippm-stamp-on-lag-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9534</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9535</doc-id>
        <title>JSONPath: Query Expressions for JSON</title>
        <author>
            <name>S. Gössner</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Normington</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bormann</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>62</page-count>
        <keywords>
            <kw>JSON</kw>
        </keywords>
        <abstract><p>JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from within a given JSON value.</p></abstract>
        <draft>draft-ietf-jsonpath-base-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jsonpath</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9535</errata-url>
        <doi>10.17487/RFC9535</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9536</doc-id>
        <title>Registration Data Access Protocol (RDAP) Reverse Search</title>
        <author>
            <name>M. Loffredo</name>
        </author>
        <author>
            <name>M. Martinelli</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>Reverse search</kw>
        </keywords>
        <abstract><p>The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern.  Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario.  This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class.  The reverse search based on the domain-entity relationship is treated as a particular case.</p></abstract>
        <draft>draft-ietf-regext-rdap-reverse-search-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9536</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9537</doc-id>
        <title>Redacted Fields in the Registration Data Access Protocol (RDAP) Response</title>
        <author>
            <name>J. Gould</name>
        </author>
        <author>
            <name>D. Smith</name>
        </author>
        <author>
            <name>J. Kolker</name>
        </author>
        <author>
            <name>R. Carney</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>Redacted</kw>
            <kw>Redaction</kw>
            <kw>Redacting</kw>
            <kw>JSONPath</kw>
        </keywords>
        <abstract><p>This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.</p></abstract>
        <draft>draft-ietf-regext-rdap-redacted-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9537</errata-url>
        <doi>10.17487/RFC9537</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9538</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment</title>
        <author>
            <name>F. Fieau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Stephan</name>
        </author>
        <author>
            <name>S. Mishra</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>HTTPS</kw>
            <kw>delegation</kw>
            <kw>ACME</kw>
            <kw>STAR</kw>
        </keywords>
        <abstract><p>This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected Content Delivery Networks (CDNs).  Specifically, this document defines a Content Delivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC 9115.  Per RFC 9115, delegating entities can remain in full control of the delegation and can revoke it at any time.  This avoids the need to share private cryptographic key material between the involved entities.</p></abstract>
        <draft>draft-ietf-cdni-delegation-acme-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC9538</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9539</doc-id>
        <title>Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS</title>
        <author>
            <name>D. K. Gillmor</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Salazar</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Hoffman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>DNS over TLS</kw>
            <kw>DNS over QUIC</kw>
            <kw>ToT</kw>
            <kw>DoQ</kw>
            <kw>encryption</kw>
            <kw>unilateral</kw>
            <kw>recursive</kw>
            <kw>authoritative</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract><p>This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses.</p><p> The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks.</p></abstract>
        <draft>draft-ietf-dprive-unilateral-probing-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dprive</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9539</errata-url>
        <doi>10.17487/RFC9539</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9540</doc-id>
        <title>Discovery of Oblivious Services via Service Binding Records</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>Oblivious HTTP</kw>
            <kw>SVCB</kw>
        </keywords>
        <abstract><p>This document defines a parameter that can be included in Service Binding (SVCB) and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an Oblivious Gateway Resource through which to access the target.  This document also defines a mechanism for learning the key configuration of the discovered Oblivious Gateway Resource.</p></abstract>
        <draft>draft-ietf-ohai-svcb-config-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ohai</wg_acronym>
        <doi>10.17487/RFC9540</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9541</doc-id>
        <title>Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <author>
            <name>K. Nagaraj</name>
        </author>
        <author>
            <name>M. Miyake</name>
        </author>
        <author>
            <name>T. Matsuda</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPNs) to deploy Ethernet Local Area Network (E-LAN) services in large Multiprotocol Label Switching (MPLS) networks.  That combination is what we refer to as "PBB-EVPN." Single-Active multihoming and per Service Instance Identifier (I-SID) load-balancing can be provided to access devices and aggregation networks.  In order to speed up the network convergence in case of failures on Single-Active multihomed Ethernet Segments (ESs), PBB-EVPN defines a flush mechanism for Customer MACs (C-MACs) called "C-MAC flush" that works for different Ethernet Segment Backbone MAC (B-MAC) address allocation models.  This document complements those C-MAC flush procedures for cases in which no PBB-EVPN ESs are defined (i.e., the attachment circuit is associated with a zero Ethernet Segment Identifier (ESI)) and the C-MAC flush requires I-SID-level granularity.</p></abstract>
        <draft>draft-ietf-bess-pbb-evpn-isid-cmacflush-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9541</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9542</doc-id>
        <title>IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>Y. Li</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>Ethernet</kw>
            <kw>EtherType</kw>
            <kw>802</kw>
            <kw>OUI</kw>
            <kw>EUI</kw>
            <kw>LSAP</kw>
            <kw>AFN</kw>
            <kw>CBOR</kw>
            <kw>LLC</kw>
            <kw>SLAP</kw>
            <kw>SNAP</kw>
            <kw>CID</kw>
        </keywords>
        <abstract><p>Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters.  This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation.  This document obsoletes RFC 7042.</p></abstract>
        <draft>draft-ietf-intarea-rfc7042bis-11</draft>
        <obsoletes>
            <doc-id>RFC7042</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0141</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>intarea</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9542</errata-url>
        <doi>10.17487/RFC9542</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9543</doc-id>
        <title>A Framework for Network Slices in Networks Built from IETF Technologies</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Drake</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Rokui</name>
        </author>
        <author>
            <name>S. Homma</name>
        </author>
        <author>
            <name>K. Makhijani</name>
        </author>
        <author>
            <name>L. Contreras</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>Network Slicing</kw>
        </keywords>
        <abstract><p>This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.</p><p> The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.</p><p> This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices.</p></abstract>
        <draft>draft-ietf-teas-ietf-network-slices-25</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9543</errata-url>
        <doi>10.17487/RFC9543</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9544</doc-id>
        <title>Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>X. Min</name>
        </author>
        <author>
            <name>A. Clemm</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>J. François</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>IPPM</kw>
            <kw>Performance Measurement</kw>
        </keywords>
        <abstract><p>This document defines a set of metrics for networking services with
performance requirements expressed as Service Level Objectives
(SLOs).  These metrics, referred to as "Precision Availability Metrics
(PAMs)", are useful for defining and monitoring SLOs.  For example,
PAMs can be used by providers and/or customers of an RFC 9543 Network
Slice Service to assess whether the service is provided in compliance
with its defined SLOs.</p></abstract>
        <draft>draft-ietf-ippm-pam-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9544</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9545</doc-id>
        <title>Path Segment Identifier in MPLS-Based Segment Routing Networks</title>
        <author>
            <name>W. Cheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Li</name>
        </author>
        <author>
            <name>C. Li</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Gandhi</name>
        </author>
        <author>
            <name>R. Zigler</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Performance Measurement</kw>
            <kw> Bidirectional SR Path </kw>
            <kw>End-to-End Path Protection</kw>
            <kw>SR Path Segment</kw>
            <kw>Path Segment</kw>
        </keywords>
        <abstract><p>A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection.</p><p> In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network.</p><p> This document defines a Path Segment Identifier (PSID) to identify an SR path on the egress node of the path.</p></abstract>
        <draft>draft-ietf-spring-mpls-path-segment-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9545</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9546</doc-id>
        <title>Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>B. Varga</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DetNet</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This document defines format and usage principles of the Deterministic Networking (DetNet) service Associated Channel over a DetNet network with the MPLS data plane.  The DetNet service Associated Channel can be used to carry test packets of active Operations, Administration, and Maintenance (OAM) protocols that are used to detect DetNet failures and measure performance metrics.</p></abstract>
        <draft>draft-ietf-detnet-mpls-oam-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9546</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9547</doc-id>
        <title>Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>C. S. Perkins</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>February</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>environment</kw>
            <kw>energy</kw>
            <kw>Internet impacts</kw>
            <kw>sustainability</kw>
        </keywords>
        <abstract><p>Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 to explore and understand these impacts.</p><p> The role of the workshop was to discuss the impacts and the evolving industry needs, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and bring together a diverse stakeholder community to discuss these issues.</p><p> Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</p></abstract>
        <draft>draft-iab-ws-environmental-impacts-report-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9547</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9548</doc-id>
        <title>Generating Transport Key Containers (PFX) Using the GOST Algorithms</title>
        <author>
            <name>E. Karelina</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>transport key containers</kw>
            <kw>certificates</kw>
            <kw>GOST algorithms</kw>
            <kw>pkcs12</kw>
            <kw>gost</kw>
            <kw>PFX</kw>
        </keywords>
        <abstract><p>This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to transport key containers (PFX) for storing keys and certificates in conjunction with the Russian national standard GOST algorithms.</p><p> This specification has been developed outside the IETF. The purpose of publication is to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here.</p></abstract>
        <draft>draft-pkcs12-gost-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9548</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9549</doc-id>
        <title>Internationalization Updates to RFC 5280</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Internationalized Email Address</kw>
        </keywords>
        <abstract><p>The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates.  The updates ensure that name constraints for email addresses that contain only ASCII characters and internationalized email addresses are handled in the same manner.  This document obsoletes RFC 8399.</p></abstract>
        <draft>draft-ietf-lamps-rfc8399bis-05</draft>
        <obsoletes>
            <doc-id>RFC8399</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9549</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9550</doc-id>
        <title>Deterministic Networking (DetNet): Packet Ordering Function</title>
        <author>
            <name>B. Varga</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>S. Kehrer</name>
        </author>
        <author>
            <name>T. Heer</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The replication and elimination functions of the Deterministic Networking (DetNet) architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications.  The Packet Ordering Function (POF) algorithms described in this document enable restoration of the correct packet order when the replication and elimination functions are used in DetNet networks.  The POF only provides ordering within the latency bound of a DetNet flow; it does not provide any additional reliability.</p></abstract>
        <draft>draft-ietf-detnet-pof-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9550</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9551</doc-id>
        <title>Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>F. Theoleyre</name>
        </author>
        <author>
            <name>G. Papadopoulos</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
        </author>
        <author>
            <name>B. Varga</name>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Metrics</kw>
            <kw>Tracing</kw>
        </keywords>
        <abstract><p>Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments.  This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network.  The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network.  With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.</p></abstract>
        <draft>draft-ietf-detnet-oam-framework-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9551</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9552</doc-id>
        <title>Distribution of Link-State and Traffic Engineering Information Using BGP</title>
        <author>
            <name>K. Talaulikar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2023</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>research</kw>
            <kw>measurement</kw>
            <kw>identification</kw>
            <kw>probing</kw>
            <kw>out-of-band</kw>
            <kw>in-band</kw>
        </keywords>
        <abstract><p>In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</p><p> This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.</p><p> Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</p><p> This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.</p></abstract>
        <draft>draft-ietf-idr-rfc7752bis-17</draft>
        <obsoletes>
            <doc-id>RFC7752</doc-id>
            <doc-id>RFC9029</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9552</errata-url>
        <doi>10.17487/RFC9552</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9553</doc-id>
        <title>JSContact: A JSON Representation of Contact Data</title>
        <author>
            <name>R. Stepanek</name>
        </author>
        <author>
            <name>M. Loffredo</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>73</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>addressbook</kw>
            <kw>contacts</kw>
            <kw>cards</kw>
            <kw>VCARD</kw>
        </keywords>
        <abstract><p>This specification defines a data model and JavaScript Object Notation (JSON) representation of contact card information that can be used for data storage and exchange in address book or directory applications.  It aims to be an alternative to the vCard data format and to be unambiguous, extendable, and simple to process.  In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate.  Two additional specifications define new vCard elements and how to convert between JSContact and vCard.</p></abstract>
        <draft>draft-ietf-calext-jscontact-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9553</errata-url>
        <doi>10.17487/RFC9553</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9554</doc-id>
        <title>vCard Format Extensions for JSContact</title>
        <author>
            <name>R. Stepanek</name>
        </author>
        <author>
            <name>M. Loffredo</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>addressbook</kw>
            <kw>contacts</kw>
            <kw>cards</kw>
            <kw>vCard</kw>
            <kw>JSContact</kw>
        </keywords>
        <abstract><p>This document defines a set of new properties for vCard and extends the use of existing ones.  Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format.  This document updates RFC 6350 ("vCard Format Specification").</p></abstract>
        <draft>draft-ietf-calext-vcard-jscontact-extensions-12</draft>
        <updates>
            <doc-id>RFC6350</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <doi>10.17487/RFC9554</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9555</doc-id>
        <title>JSContact: Converting from and to vCard</title>
        <author>
            <name>M. Loffredo</name>
        </author>
        <author>
            <name>R. Stepanek</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>60</page-count>
        <keywords>
            <kw>JSON</kw>
            <kw>contacts</kw>
            <kw>vCard</kw>
            <kw>jCard</kw>
        </keywords>
        <abstract><p>This document defines how to convert contact information between the JSContact and vCard data formats.  It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication.  It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements.</p></abstract>
        <draft>draft-ietf-calext-jscontact-vcard-15</draft>
        <updates>
            <doc-id>RFC6350</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>calext</wg_acronym>
        <doi>10.17487/RFC9555</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9556</doc-id>
        <title>Internet of Things (IoT) Edge Challenges and Functions</title>
        <author>
            <name>J. Hong</name>
        </author>
        <author>
            <name>Y-G. Hong</name>
        </author>
        <author>
            <name>X. de Foy</name>
        </author>
        <author>
            <name>M. Kovatsch</name>
        </author>
        <author>
            <name>E. Schooler</name>
        </author>
        <author>
            <name>D. Kutscher</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>in-network computing</kw>
            <kw>in-network caching</kw>
            <kw>in-network storage</kw>
        </keywords>
        <abstract><p>Many Internet of Things (IoT) applications have requirements that cannot be satisfied by centralized cloud-based systems (i.e., cloud computing).  These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security.  As a result, IoT is driving the Internet toward edge computing.  This document outlines the requirements of the emerging IoT edge and its challenges.  It presents a general model and major components of the IoT edge to provide a common basis for future discussions in the Thing-to-Thing Research Group (T2TRG) and other IRTF and IETF groups.  This document is a product of the IRTF T2TRG.</p></abstract>
        <draft>draft-irtf-t2trg-iot-edge-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9556</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9557</doc-id>
        <title>Date and Time on the Internet: Timestamps with Additional Information</title>
        <author>
            <name>U. Sharma</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Gregorian calendar</kw>
            <kw>Calendar awareness</kw>
            <kw>Time zone</kw>
            <kw>ISO 8601</kw>
            <kw>Temporal</kw>
            <kw>RFC 3339</kw>
            <kw>Extension</kw>
            <kw>Internet Extended Date/Time Format</kw>
            <kw>IXDTF</kw>
        </keywords>
        <abstract><p>This document defines an extension to the timestamp format defined in RFC 3339 for representing additional information, including a time zone.</p><p> It updates RFC 3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time".</p></abstract>
        <draft>draft-ietf-sedate-datetime-extended-11</draft>
        <updates>
            <doc-id>RFC3339</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sedate</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9557</errata-url>
        <doi>10.17487/RFC9557</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9558</doc-id>
        <title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC</title>
        <author>
            <name>B. Makarenko</name>
        </author>
        <author>
            <name>V. Dolmatov</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).</p></abstract>
        <draft>draft-makarenko-gost2012-dnssec-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9558</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9559</doc-id>
        <title>Matroska Media Container Format Specification</title>
        <author>
            <name>S. Lhomme</name>
        </author>
        <author>
            <name>M. Bunkus</name>
        </author>
        <author>
            <name>D. Rice</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>157</page-count>
        <keywords>
            <kw>binary</kw>
            <kw>storage</kw>
            <kw>matroska</kw>
            <kw>ebml</kw>
            <kw>webm</kw>
        </keywords>
        <abstract><p>This document defines the Matroska audiovisual data container structure, including definitions of its structural elements, terminology, vocabulary, and application.</p><p> This document updates RFC 8794 to permit the use of a previously reserved Extensible Binary Meta Language (EBML) Element ID.</p></abstract>
        <draft>draft-ietf-cellar-matroska-21</draft>
        <updates>
            <doc-id>RFC8794</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cellar</wg_acronym>
        <doi>10.17487/RFC9559</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9560</doc-id>
        <title>Federated Authentication for the Registration Data Access Protocol (RDAP) Using OpenID Connect</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>RDAP</kw>
            <kw>Federated</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract><p>The Registration Data Access Protocol (RDAP) provides Representational State Transfer (RESTful) web services to retrieve registration metadata from domain name and regional internet registries.  RDAP allows a server to make access control decisions based on client identity, and as such, it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP).  Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials.  This document describes a federated authentication system for RDAP based on OpenID Connect.</p></abstract>
        <draft>draft-ietf-regext-rdap-openid-27</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9560</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9561</doc-id>
        <title>Using the Parallel NFS (pNFS) SCSI Layout to Access Non-Volatile Memory Express (NVMe) Storage Devices</title>
        <author>
            <name>C. Hellwig</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Lever</name>
        </author>
        <author>
            <name>S. Faibish</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>This document specifies how to use the Parallel Network File System (pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family.</p></abstract>
        <draft>draft-ietf-nfsv4-scsi-layout-nvme-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC9561</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9562</doc-id>
        <title>Universally Unique IDentifiers (UUIDs)</title>
        <author>
            <name>K. Davis</name>
        </author>
        <author>
            <name>B. Peabody</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>uuid</kw>
        </keywords>
        <abstract><p>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</p><p> This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</p></abstract>
        <draft>draft-ietf-uuidrev-rfc4122bis-14</draft>
        <obsoletes>
            <doc-id>RFC4122</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>uuidrev</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9562</errata-url>
        <doi>10.17487/RFC9562</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9563</doc-id>
        <title>SM2 Digital Signature Algorithm for DNSSEC</title>
        <author>
            <name>C. Zhang</name>
        </author>
        <author>
            <name>Y. Liu</name>
        </author>
        <author>
            <name>F. Leng</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>Z. He</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC).</p><p> This document is an Independent Submission to the RFC series and does not have consensus of the IETF community.</p></abstract>
        <draft>draft-cuiling-dnsop-sm2-alg-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9563</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9564</doc-id>
        <title>Faster Than Light Speed Protocol (FLIP)</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>LLM</kw>
            <kw>IP</kw>
        </keywords>
        <abstract><p>The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speed Protocol (FLIP) for Internet.  FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive.  This document describes the protocol, its various encapsulations, and some operational considerations.</p></abstract>
        <draft>draft-blanchet-flip-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9564</errata-url>
        <doi>10.17487/RFC9564</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9565</doc-id>
        <title>An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>March</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>TCP</kw>
            <kw>Measurement</kw>
            <kw>Export</kw>
            <kw>Observability</kw>
        </keywords>
        <abstract><p>RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated.</p><p> This document removes stale information from the IANA "IPFIX Information Elements" registry and avoids future conflicts with the authoritative IANA "TCP Header Flags" registry.</p><p> This document obsoletes RFC 7125.</p></abstract>
        <draft>draft-ietf-opsawg-rfc7125-update-07</draft>
        <obsoletes>
            <doc-id>RFC7125</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9565</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9566</doc-id>
        <title>Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP</title>
        <author>
            <name>B. Varga</name>
        </author>
        <author>
            <name>J. Farkas</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IP Data Plane</kw>
            <kw>Service sub-layer</kw>
            <kw>Replication</kw>
            <kw>Elimination</kw>
            <kw>Ordering</kw>
        </keywords>
        <abstract><p>This document describes how the DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for the DetNet MPLS data plane and the mechanisms defined by MPLS-over-UDP technology.</p></abstract>
        <draft>draft-ietf-detnet-mpls-over-ip-preof-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9566</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9567</doc-id>
        <title>DNS Error Reporting</title>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>M. Larson</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>monitoring</kw>
            <kw>agent</kw>
            <kw>RFC8914</kw>
            <kw>8914</kw>
        </keywords>
        <abstract><p>DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914.</p><p> When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME; thus, the very act of sending the query is to report the error.</p></abstract>
        <draft>draft-ietf-dnsop-dns-error-reporting-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9567</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9568</doc-id>
        <title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>A. Dogra</name>
        </author>
        <date>
            <month>April</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6.  It obsoletes RFC 5798, which previously specified VRRP (version 3).  RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4.  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 IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses.  Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version.  Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances.  The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable.  For IPv4, 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.  For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms.</p></abstract>
        <draft>draft-ietf-rtgwg-vrrp-rfc5798bis-18</draft>
        <obsoletes>
            <doc-id>RFC5798</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rtgwg</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9568</errata-url>
        <doi>10.17487/RFC9568</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9569</doc-id>
        <title>The Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service (TIPS)</title>
        <author>
            <name>K. Gao</name>
        </author>
        <author>
            <name>R. Schott</name>
        </author>
        <author>
            <name>Y. R. Yang</name>
        </author>
        <author>
            <name>L. Delwiche</name>
        </author>
        <author>
            <name>L. Keller</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>40</page-count>
        <keywords>
            <kw>incremental update</kw>
        </keywords>
        <abstract><p>"Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources and the server responds with the complete content of each resource, one at a time.</p><p> RFC 8895, which describes ALTO incremental updates using Server-Sent Events (SSE), defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection.</p><p> To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly and concurrently (in a non-blocking manner) request (or pull) specific incremental updates using HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.</p></abstract>
        <draft>draft-ietf-alto-new-transport-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>alto</wg_acronym>
        <doi>10.17487/RFC9569</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9570</doc-id>
        <title>Deprecating the Use of Router Alert in LSP Ping</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>LSP ping</kw>
            <kw>router alert</kw>
        </keywords>
        <abstract><p>The MPLS echo request and MPLS echo response messages, defined in RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to as LSP ping), are encapsulated in IP packets with headers that include a Router Alert Option (RAO). In actual deployments, the RAO was neither required nor used. Furthermore, RFC 6398 identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of using the MPLS echo request/reply as inter-area Operations, Administration, and Maintenance (OAM), and recommends against its use outside of controlled environments.</p><p> Therefore, this document retires the RAO for MPLS OAM and updates RFC 8029 to remove the RAO from LSP ping message encapsulations. Furthermore, this document explains why RFC 7506 has been reclassified as Historic.</p><p> Also, this document recommends the use of an IPv6 loopback address (::1/128) as the IPv6 destination address for an MPLS echo request message.</p></abstract>
        <draft>draft-ietf-mpls-lspping-norao-08</draft>
        <updates>
            <doc-id>RFC8029</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9570</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9571</doc-id>
        <title>Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>G. Fioccola</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as they are used in MPLS Transport Profile (MPLS-TP) networks.  This document describes a method of extending the performance measurements (specified in RFC 6374) from flows carried over MPLS-TP to flows carried over generic MPLS LSPs.  In particular, it extends the technique to allow loss and delay measurements to be made on multipoint-to-point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and generic MPLS networks.</p></abstract>
        <draft>draft-ietf-mpls-rfc6374-sfl-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9571</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9572</doc-id>
        <title>Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>per-region I-PMSI</kw>
            <kw>selective multicast forwarding</kw>
            <kw>tunnel segmentation</kw>
            <kw>inter-AS segmentation</kw>
            <kw>inter-region segmentation</kw>
        </keywords>
        <abstract><p>This document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels.  This document updates RFC 7432.</p></abstract>
        <draft>draft-ietf-bess-evpn-bum-procedure-updates-14</draft>
        <updates>
            <doc-id>RFC7432</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9572</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9573</doc-id>
        <title>MVPN/EVPN Tunnel Aggregation with Common Labels</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>DCB</kw>
            <kw>Tunnel Aggregation</kw>
        </keywords>
        <abstract><p>The Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document).  The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs).  These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD.  A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels.  The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs.  However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD.  New procedures are needed in order to take advantage of such provisioned labels.  These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels.  This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures.</p></abstract>
        <draft>draft-ietf-bess-mvpn-evpn-aggregation-label-14</draft>
        <updates>
            <doc-id>RFC6514</doc-id>
            <doc-id>RFC7432</doc-id>
            <doc-id>RFC7582</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9573</errata-url>
        <doi>10.17487/RFC9573</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9574</doc-id>
        <title>Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs)</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>M. Katiyar</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Assisted Replication</kw>
            <kw>AR</kw>
            <kw>AR-Replicator</kw>
            <kw>RNVE</kw>
            <kw>Pruned Flood List</kw>
            <kw>PFL</kw>
            <kw>Pruned Flooding List</kw>
        </keywords>
        <abstract><p>Network Virtualization Overlay (NVO) networks using Ethernet VPNs (EVPNs) as their control plane may use trees based on ingress replication or Protocol Independent Multicast (PIM) to convey the overlay Broadcast, Unknown Unicast, or Multicast (BUM) traffic.  PIM provides an efficient solution that prevents sending multiple copies of the same packet over the same physical link; however, it may not always be deployed in the NVO network core.  Ingress replication avoids the dependency on PIM in the NVO network core.  While ingress replication provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core.  This document describes a solution to optimize the efficiency of ingress replication trees.</p></abstract>
        <draft>draft-ietf-bess-evpn-optimized-ir-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9574</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9575</doc-id>
        <title>DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)</title>
        <author>
            <name>A. Wiethuechter</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Card</name>
        </author>
        <author>
            <name>R. Moskowitz</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>43</page-count>
        <keywords>
            <kw>drone</kw>
            <kw>UAS</kw>
            <kw>Broadcast RID</kw>
            <kw>trustworthy remote identification</kw>
            <kw>anti-spoofing</kw>
        </keywords>
        <abstract><p>The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access.  This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed.</p></abstract>
        <draft>draft-ietf-drip-auth-49</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>drip</wg_acronym>
        <doi>10.17487/RFC9575</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9576</doc-id>
        <title>The Privacy Pass Architecture</title>
        <author>
            <name>A. Davidson</name>
        </author>
        <author>
            <name>J. Iyengar</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms.  It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled.</p></abstract>
        <draft>draft-ietf-privacypass-architecture-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>privacypass</wg_acronym>
        <doi>10.17487/RFC9576</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9577</doc-id>
        <title>The Privacy Pass HTTP Authentication Scheme</title>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>S. Valdez</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>anonymous</kw>
            <kw>authorization</kw>
            <kw>crypto</kw>
        </keywords>
        <abstract><p>This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization.  The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin.  It can also be used by Origins to challenge Clients to present Privacy Pass tokens.</p></abstract>
        <draft>draft-ietf-privacypass-auth-scheme-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>privacypass</wg_acronym>
        <doi>10.17487/RFC9577</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9578</doc-id>
        <title>Privacy Pass Issuance Protocols</title>
        <author>
            <name>S. Celi</name>
        </author>
        <author>
            <name>A. Davidson</name>
        </author>
        <author>
            <name>S. Valdez</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <abstract><p>This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key.  Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol.</p></abstract>
        <draft>draft-ietf-privacypass-protocol-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>privacypass</wg_acronym>
        <doi>10.17487/RFC9578</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9579</doc-id>
        <title>Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax</title>
        <author>
            <name>H. Kario</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>pbmac1</kw>
            <kw>pkcs12</kw>
            <kw>pbkdf2</kw>
        </keywords>
        <abstract><p>This document specifies additions and amendments to RFCs 7292 and 8018.  It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax.  The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance.</p></abstract>
        <draft>draft-ietf-lamps-pkcs12-pbmac1-08</draft>
        <updates>
            <doc-id>RFC7292</doc-id>
            <doc-id>RFC8018</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9579</errata-url>
        <doi>10.17487/RFC9579</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9580</doc-id>
        <title>OpenPGP</title>
        <author>
            <name>P. Wouters</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Huigens</name>
        </author>
        <author>
            <name>J. Winter</name>
        </author>
        <author>
            <name>Y. Niibe</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>166</page-count>
        <keywords>
            <kw>encryption</kw>
            <kw>digital signatures</kw>
            <kw>key management</kw>
            <kw>pgp</kw>
        </keywords>
        <abstract><p>This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management.</p><p> This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</p><p> This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP").</p></abstract>
        <draft>draft-ietf-openpgp-crypto-refresh-13</draft>
        <obsoletes>
            <doc-id>RFC4880</doc-id>
            <doc-id>RFC5581</doc-id>
            <doc-id>RFC6637</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>openpgp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9580</errata-url>
        <doi>10.17487/RFC9580</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9581</doc-id>
        <title>Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>B. Gamari</name>
        </author>
        <author>
            <name>H. Birkholz</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>Point in time</kw>
            <kw>Duration</kw>
            <kw>Period in time</kw>
            <kw>Clock accuracy</kw>
            <kw>Timescale</kw>
            <kw>TAI</kw>
            <kw>UTC</kw>
            <kw>NTP</kw>
            <kw>Network Time Protocol</kw>
            <kw>PTP</kw>
            <kw>Precision Time Protocol</kw>
        </keywords>
        <abstract><p>The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.</p><p> In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC 3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined.</p></abstract>
        <draft>draft-ietf-cbor-time-tag-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC9581</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9582</doc-id>
        <title>A Profile for Route Origin Authorizations (ROAs)</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>B. Maddison</name>
        </author>
        <author>
            <name>M. Lepinski</name>
        </author>
        <author>
            <name>D. Kong</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>Routing Security</kw>
            <kw>BGP</kw>
        </keywords>
        <abstract><p>This document defines a standard profile for Route Origin Authorizations (ROAs).  A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block.  This document obsoletes RFC 6482.</p></abstract>
        <draft>draft-ietf-sidrops-rfc6482bis-09</draft>
        <obsoletes>
            <doc-id>RFC6482</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9582</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9583</doc-id>
        <title>Application Scenarios for the Quantum Internet</title>
        <author>
            <name>C. Wang</name>
        </author>
        <author>
            <name>A. Rahman</name>
        </author>
        <author>
            <name>R. Li</name>
        </author>
        <author>
            <name>M. Aelmans</name>
        </author>
        <author>
            <name>K. Chakraborty</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>Quantum Key Distribution</kw>
            <kw>Blind Quantum Computing</kw>
            <kw>Distributed Quantum Computing</kw>
            <kw>Entanglement Distribution</kw>
            <kw>Quantum Internet Requirement</kw>
        </keywords>
        <abstract><p>The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet.  This document provides an overview of some applications expected to be used on the Quantum Internet and categorizes them.  Some general requirements for the Quantum Internet are also discussed.  The intent of this document is to describe a framework for applications and to describe a few selected application scenarios for the Quantum Internet.  This document is a product of the Quantum Internet Research Group (QIRG).</p></abstract>
        <draft>draft-irtf-qirg-quantum-internet-use-cases-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9583</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9584</doc-id>
        <title>RTP Payload Format for Essential Video Coding (EVC)</title>
        <author>
            <name>S. Zhao</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>Y. Lim</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>EVC</kw>
            <kw>ISO/IEC 23094-1</kw>
            <kw>Essential Video Coding</kw>
        </keywords>
        <abstract><p>This document describes an RTP payload format for the Essential Video Coding (EVC) standard, published as ISO/IEC International Standard 23094-1.  EVC was developed by the MPEG.  The RTP payload format allows for the packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload and the fragmentation of a NAL unit into multiple RTP packets.  The payload format has broad applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-evc-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9584</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9585</doc-id>
        <title>IMAP Response Code for Command Progress Notifications</title>
        <author>
            <name>M. Bettini</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>response code</kw>
        </keywords>
        <abstract><p>This document defines a new IMAP untagged response code, "INPROGRESS", that provides progress notifications regarding the status of long-running commands.</p></abstract>
        <draft>draft-ietf-extra-imap-inprogress-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9585</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9586</doc-id>
        <title>IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>A. P. Achuthan</name>
        </author>
        <author>
            <name>V. Nagulakonda</name>
        </author>
        <author>
            <name>A. Singh</name>
        </author>
        <author>
            <name>L. Alves</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>UIDONLY</kw>
            <kw>IMAP4rev1</kw>
            <kw>IMAP4rev2</kw>
        </keywords>
        <abstract><p>The UIDONLY extension to the Internet Message Access Protocol (RFCs 3501 and 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses and cannot be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs.</p><p> This document defines an experimental IMAP extension.</p></abstract>
        <draft>draft-ietf-extra-imap-uidonly-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9586</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9587</doc-id>
        <title>YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)</title>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>S. Palani</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <abstract><p>This document defines a YANG data model augmenting the IETF OSPF YANG data model (RFC 9129) to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340.</p></abstract>
        <draft>draft-ietf-lsr-ospfv3-extended-lsa-yang-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9587</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9588</doc-id>
        <title>Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre-authentication</title>
        <author>
            <name>N. McCallum</name>
        </author>
        <author>
            <name>S. Sorce</name>
        </author>
        <author>
            <name>R. Harwood</name>
        </author>
        <author>
            <name>G. Hudson</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>This document defines a new pre-authentication mechanism for the Kerberos protocol.  The mechanism uses a password-authenticated key exchange (PAKE) to prevent brute-force password attacks, and it may incorporate a second factor.</p></abstract>
        <draft>draft-ietf-kitten-krb-spake-preauth-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>kitten</wg_acronym>
        <doi>10.17487/RFC9588</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9589</doc-id>
        <title>On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>T. Harrison</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>CMS</kw>
            <kw>signing-time</kw>
        </keywords>
        <abstract><p>In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types.  A Signed Object contains a signing-time attribute, representing the purported time at which the object was signed by its issuer.  RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories.  This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols.  This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute.</p></abstract>
        <draft>draft-ietf-sidrops-cms-signing-time-07</draft>
        <updates>
            <doc-id>RFC6488</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9589</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9590</doc-id>
        <title>IMAP Extension for Returning Mailbox METADATA in Extended LIS</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <author>
            <name>B. Gondwana</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IMAP4</kw>
            <kw>LIST</kw>
            <kw>METADATA</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command.</p></abstract>
        <draft>draft-ietf-extra-imap-list-metadata-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9590</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9591</doc-id>
        <title>The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures</title>
        <author>
            <name>D. Connolly</name>
        </author>
        <author>
            <name>C. Komlo</name>
        </author>
        <author>
            <name>I. Goldberg</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>Threshold signature</kw>
            <kw>threshold cryptography</kw>
            <kw>secret sharing</kw>
            <kw>EdDSA signature</kw>
            <kw>Schnorr signature</kw>
        </keywords>
        <abstract><p>This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol.  FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key.  FROST depends only on a prime-order group and cryptographic hash function.  This document specifies a number of ciphersuites to instantiate FROST using different prime-order groups and hash functions.  This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-frost-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9591</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9592</doc-id>
        <title>Retiring the Tao of the IETF</title>
        <author>
            <name>N. ten Oever</name>
        </author>
        <author>
            <name>G. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Tao</kw>
            <kw>archive</kw>
            <kw>retired</kw>
            <kw>inactive</kw>
            <kw>tutorial</kw>
        </keywords>
        <abstract><p>This document retires and obsoletes the Tao of the IETF as an IETF-maintained document.  This document also obsoletes RFC 6722, which describes the publication process of the Tao.  Furthermore, this document describes the rationale for the retirement of the Tao.  For archival purposes, the last version of the Tao is included in the appendix.  Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner.  This is the way.</p></abstract>
        <draft>draft-tenoever-tao-retirement-04</draft>
        <obsoletes>
            <doc-id>RFC6722</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9592</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9593</doc-id>
        <title>Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>signature</kw>
            <kw>digital signature</kw>
            <kw>credentials</kw>
            <kw>intermediate exchange</kw>
        </keywords>
        <abstract><p>This specification defines a mechanism that allows implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Associations (SAs).  This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different types for authenticating each other.</p></abstract>
        <draft>draft-ietf-ipsecme-ikev2-auth-announce-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9593</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9594</doc-id>
        <title>Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE)</title>
        <author>
            <name>F. Palombini</name>
        </author>
        <author>
            <name>M. Tiloca</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>97</page-count>
        <keywords>
            <kw>Key Management</kw>
            <kw>Access Control</kw>
            <kw>Constrained Application Protocol (CoAP)</kw>
            <kw>Secure group communication</kw>
        </keywords>
        <abstract><p>This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication.  Candidate group members that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members.  While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication.  Therefore, details are delegated to separate application profiles of this document as specialized instances that target a particular group communication approach and define how communications in the group are protected.  Compliance requirements for such application profiles are also specified.</p></abstract>
        <draft>draft-ietf-ace-key-groupcomm-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9594</errata-url>
        <doi>10.17487/RFC9594</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9595</doc-id>
        <title>YANG Schema Item iDentifier (YANG SID)</title>
        <author>
            <name>M. Veillette</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Pelov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Petrov</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>44</page-count>
        <keywords>
            <kw>CBOR</kw>
        </keywords>
        <abstract><p>YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items.  SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228).  This document defines the semantics, registration processes, and assignment processes for YANG SIDs for IETF-managed YANG modules.  To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs.</p></abstract>
        <draft>draft-ietf-core-sid-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9595</errata-url>
        <doi>10.17487/RFC9595</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9596</doc-id>
        <title>CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter</title>
        <author>
            <name>M.B. Jones</name>
        </author>
        <author>
            <name>O. Steele</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Explicit Typing</kw>
        </keywords>
        <abstract><p>This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) "typ" (type) header parameter to CBOR Object Signing and Encryption (COSE).  This enables the benefits of explicit typing (as defined in RFC 8725, "JSON Web Token Best Current Practices") to be brought to COSE objects.  The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter.</p></abstract>
        <draft>draft-ietf-cose-typ-header-parameter-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC9596</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9597</doc-id>
        <title>CBOR Web Token (CWT) Claims in COSE Headers</title>
        <author>
            <name>T. Looker</name>
        </author>
        <author>
            <name>M.B. Jones</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>COSE</kw>
            <kw>JOSE</kw>
        </keywords>
        <abstract><p>This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure.  This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload.  Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all.</p></abstract>
        <draft>draft-ietf-cose-cwt-claims-in-headers-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <doi>10.17487/RFC9597</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9598</doc-id>
        <title>Internationalized Email Addresses in X.509 Certificates</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>W. Chuang</name>
        </author>
        <author>
            <name>C. Bonnell</name>
        </author>
        <date>
            <month>May</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>EAI</kw>
            <kw>PKIX</kw>
            <kw>email address</kw>
        </keywords>
        <abstract><p>This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.</p><p> This document updates RFC 5280 and obsoletes RFC 8398.</p></abstract>
        <draft>draft-ietf-lamps-rfc8398bis-05</draft>
        <obsoletes>
            <doc-id>RFC8398</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9598</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9599</doc-id>
        <title>Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP</title>
        <author>
            <name>B. Briscoe</name>
        </author>
        <author>
            <name>J. Kaippallimalil</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>Congestion Control and Management</kw>
            <kw>Congestion Notification</kw>
            <kw>Information Security</kw>
            <kw>Tunnelling</kw>
            <kw>Encapsulation</kw>
            <kw>Decapsulation</kw>
            <kw>Protocol</kw>
            <kw>ECN</kw>
            <kw>Layering</kw>
        </keywords>
        <abstract><p>The purpose of this document is to guide the design of congestion notification in any lower-layer or tunnelling protocol that encapsulates IP.  The aim is for explicit congestion signals to propagate consistently from lower-layer protocols into IP.  Then, the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4).  Specifications that follow these guidelines, whether produced by the IETF or other standards bodies, should assure interworking among IP-layer and lower-layer congestion notification mechanisms.  This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about Explicit Congestion Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference to this document.</p></abstract>
        <draft>draft-ietf-tsvwg-ecn-encap-guidelines-22</draft>
        <updates>
            <doc-id>RFC3819</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0089</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9599</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9600</doc-id>
        <title>TRansparent Interconnection of Lots of Links (TRILL): Explicit Congestion Notification (ECN) Support</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Congestion</kw>
            <kw>L4S</kw>
            <kw>RBridge</kw>
        </keywords>
        <abstract><p>Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets.  This can improve network efficiency through better congestion control without packet drops.  This document extends ECN to TRansparent Interconnection of Lots of Links (TRILL) switches, including integration with IP ECN, and provides for ECN marking in the TRILL header extension flags word (RFC 7179).</p></abstract>
        <draft>draft-ietf-trill-ecn-support-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>trill</wg_acronym>
        <doi>10.17487/RFC9600</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9601</doc-id>
        <title>Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim</title>
        <author>
            <name>B. Briscoe</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>Congestion Control and Management</kw>
            <kw>Congestion Notification</kw>
            <kw>Information Security</kw>
            <kw>Tunnelling</kw>
            <kw>Encapsulation &amp; Decapsulation</kw>
            <kw>Protocol</kw>
            <kw>ECN</kw>
            <kw>Layering</kw>
        </keywords>
        <abstract><p>RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of Explicit Congestion Notification (ECN) consistent for all forms of IP-in-IP tunnel.  This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide-area packet forwarding.  It surveys widely deployed IP tunnelling protocols that use such shim headers and updates the specifications of those that do not mention ECN propagation (including RFCs 2661, 3931, 2784, 4380 and 7450, which specify L2TPv2, L2TPv3, Generic Routing Encapsulation (GRE), Teredo, and Automatic Multicast Tunneling (AMT), respectively).  This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe.</p></abstract>
        <draft>draft-ietf-tsvwg-rfc6040update-shim-23</draft>
        <updates>
            <doc-id>RFC2661</doc-id>
            <doc-id>RFC2784</doc-id>
            <doc-id>RFC3931</doc-id>
            <doc-id>RFC4380</doc-id>
            <doc-id>RFC6040</doc-id>
            <doc-id>RFC7450</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9601</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9602</doc-id>
        <title>Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture</title>
        <author>
            <name>S. Krishnan</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>prefix allocation</kw>
        </keywords>
        <abstract><p>Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane.  Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations.  This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture.  This document allocates and makes a dedicated prefix available for SRv6 SIDs.</p></abstract>
        <draft>draft-ietf-6man-sids-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9602</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9603</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing</title>
        <author>
            <name>C. Li</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Kaladharan</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>M. Koldychev</name>
        </author>
        <author>
            <name>Y. Zhu</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>PCEP</kw>
            <kw>SRv6</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm.</p><p> An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE).</p><p> Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP.</p></abstract>
        <draft>draft-ietf-pce-segment-routing-ipv6-25</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9603</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9604</doc-id>
        <title>Carrying Binding Label/SID in PCE-Based Networks</title>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>C. Li</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (BSID), as described in RFC 8402.  It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering (TE) Label Switched Path (LSP) or an SR TE path.  The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies.  This document specifies the concept of binding value, which can be either an MPLS label or a Segment Identifier (SID).  It further specifies an extension to Path Computation Element Communication Protocol (PCEP) for reporting the binding value by a Path Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based TE policies.</p></abstract>
        <draft>draft-ietf-pce-binding-label-sid-16</draft>
        <updated-by>
            <doc-id>RFC9756</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9604</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9605</doc-id>
        <title>Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media</title>
        <author>
            <name>E. Omara</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>S. G. Murillo</name>
        </author>
        <author>
            <name>R. Barnes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y. Fablet</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>68</page-count>
        <keywords>
            <kw>security</kw>
            <kw>real-time media encryption</kw>
            <kw>end-to-end encryption</kw>
        </keywords>
        <abstract><p>This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media.</p><p> This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient.</p></abstract>
        <draft>draft-ietf-sframe-enc-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sframe</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9605</errata-url>
        <doi>10.17487/RFC9605</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9606</doc-id>
        <title>DNS Resolver Information</title>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>M. Boucadair</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Transparency</kw>
            <kw>User Experience</kw>
            <kw>DNS server selection</kw>
        </keywords>
        <abstract><p>This document specifies a method for DNS resolvers to publish information about themselves.  DNS clients can use the resolver information to identify the capabilities of DNS resolvers.  How DNS clients use such information is beyond the scope of this document.</p></abstract>
        <draft>draft-ietf-add-resolver-info-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>add</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9606</errata-url>
        <doi>10.17487/RFC9606</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9607</doc-id>
        <title>RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec</title>
        <author>
            <name>D. Hanson</name>
        </author>
        <author>
            <name>M. Faller</name>
        </author>
        <author>
            <name>K. Maver</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP).  SCIP is an application-layer protocol that provides end-to-end session establishment, payload encryption, packetization and de-packetization of media, and reliable transport.  This document provides a globally available reference that can be used for the development of network equipment and procurement of services that support SCIP traffic.  The intended audience is network security policymakers; network administrators, architects, and original equipment manufacturers (OEMs); procurement personnel; and government agency and commercial industry representatives.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-scip-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9607</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9608</doc-id>
        <title>No Revocation Available for X.509 Public Key Certificates</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Okubo</name>
        </author>
        <author>
            <name>J. Mandel</name>
        </author>
        <date>
            <month>June</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>X.509v3 public key certificates are profiled in RFC 5280.  Short-lived certificates are seeing greater use in the Internet.  The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information.  Some long-lived X.509v3 public key certificates never expire, and they are never revoked.  This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm defined in RFC 5280 so that revocation checking is skipped when the noRevAvail certificate extension is present.</p></abstract>
        <draft>draft-ietf-lamps-norevavail-04</draft>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9608</errata-url>
        <doi>10.17487/RFC9608</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9609</doc-id>
        <title>Initializing a DNS Resolver with Priming Queries</title>
        <author>
            <name>P. Koch</name>
        </author>
        <author>
            <name>M. Larson</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>DNS caching</kw>
            <kw>root zone</kw>
        </keywords>
        <abstract><p>This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers.</p><p> This document obsoletes RFC 8109.</p></abstract>
        <draft>draft-ietf-dnsop-rfc8109bis-07</draft>
        <obsoletes>
            <doc-id>RFC8109</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0209</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9609</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9610</doc-id>
        <title>JSON Meta Application Protocol (JMAP) for Contacts</title>
        <author>
            <name>N. Jenkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
            <kw>contacts</kw>
        </keywords>
        <abstract><p>This document specifies a data model for synchronising contact data with a server using the JSON Meta Application Protocol (JMAP).</p></abstract>
        <draft>draft-ietf-jmap-contacts-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9610</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9611</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per-Resource Child Security Associations (SAs)</title>
        <author>
            <name>A. Antony</name>
        </author>
        <author>
            <name>T. Brunner</name>
        </author>
        <author>
            <name>S. Klassert</name>
        </author>
        <author>
            <name>P. Wouters</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>IKEv2</kw>
            <kw>IPsec</kw>
        </keywords>
        <abstract><p>In order to increase the bandwidth of IPsec traffic between peers, this document defines one Notify Message Status Types and one Notify Message Error Types payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child Security Associations (SAs) with the same Traffic Selectors used on different resources, such as CPUs.</p><p> The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination.</p><p> Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their cryptographic state or disable their packet replay protection.</p></abstract>
        <draft>draft-ietf-ipsecme-multi-sa-performance-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ipsecme</wg_acronym>
        <doi>10.17487/RFC9611</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9612</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <author>
            <name>I. Varlashkin</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <keywords>
            <kw>LSP Ping</kw>
            <kw>BFD</kw>
        </keywords>
        <abstract><p>Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems.  When a BFD session monitors an explicitly routed unidirectional path, there may be a need to direct the egress BFD peer to use a specific path for the reverse direction of the BFD session.  This document describes an extension to the MPLS Label Switched Path (LSP) echo request that allows a BFD system to request that the remote BFD peer transmit BFD control packets over the specified LSP.</p></abstract>
        <draft>draft-ietf-mpls-bfd-directed-31</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9612</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9613</doc-id>
        <title>Requirements for Solutions that Support MPLS Network Actions (MNAs)</title>
        <author>
            <name>M. Bocci</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <abstract><p>This document specifies requirements for the development of MPLS Network Actions (MNAs) that affect the forwarding or other processing of MPLS packets.  These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router - LER).</p></abstract>
        <draft>draft-ietf-mpls-mna-requirements-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9613</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9614</doc-id>
        <title>Partitioning as an Architecture for Privacy</title>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>MASQUE</kw>
            <kw>Privacy Pass</kw>
            <kw>Oblivious HTTP</kw>
            <kw>Proxy</kw>
        </keywords>
        <abstract><p>This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve privacy by separating user identity from user data.  This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models.</p></abstract>
        <draft>draft-iab-privacy-partitioning-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9614</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9615</doc-id>
        <title>Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator</title>
        <author>
            <name>P. Thomassen</name>
        </author>
        <author>
            <name>N. Wisiol</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>bootstrapping</kw>
            <kw>DS</kw>
            <kw>CDS</kw>
            <kw>CDNSKEY</kw>
        </keywords>
        <abstract><p>This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated.</p><p> Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay".</p><p> This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344.</p></abstract>
        <draft>draft-ietf-dnsop-dnssec-bootstrapping-11</draft>
        <updates>
            <doc-id>RFC7344</doc-id>
            <doc-id>RFC8078</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9615</errata-url>
        <doi>10.17487/RFC9615</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9616</doc-id>
        <title>Delay-Based Metric Extension for the Babel Routing Protocol</title>
        <author>
            <name>B. Jonglez</name>
        </author>
        <author>
            <name>J. Chroboczek</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>Timestamp</kw>
            <kw>clock</kw>
            <kw>NTP</kw>
            <kw>Mills</kw>
            <kw>Hello</kw>
            <kw>Fuzzball</kw>
        </keywords>
        <abstract><p>This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower-latency links over higher-latency ones.</p></abstract>
        <draft>draft-ietf-babel-rtt-extension-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC9616</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9617</doc-id>
        <title>A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)</title>
        <author>
            <name>T. Zhou</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Guichard</name>
        </author>
        <author>
            <name>F. Brockners</name>
        </author>
        <author>
            <name>S. Raghavan</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>OAM</kw>
            <kw>Configuration</kw>
        </keywords>
        <abstract><p>In situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method.  IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method.  RFCs 9197 and 9326 discuss the data fields and associated data types for IOAM.  This document defines a YANG module for the configuration of IOAM functions.</p></abstract>
        <draft>draft-ietf-ippm-ioam-yang-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>ippm</wg_acronym>
        <doi>10.17487/RFC9617</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9618</doc-id>
        <title>Updates to X.509 Policy Validation</title>
        <author>
            <name>D. Benjamin</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <abstract><p>This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm.  The original algorithm built a structure that scaled exponentially in the worst case, leaving implementations vulnerable to denial-of-service attacks.</p></abstract>
        <draft>draft-ietf-lamps-x509-policy-graph-05</draft>
        <updates>
            <doc-id>RFC5280</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9618</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9619</doc-id>
        <title>In the DNS, QDCOUNT Is (Usually) One</title>
        <author>
            <name>R. Bellis</name>
        </author>
        <author>
            <name>J. Abley</name>
        </author>
        <date>
            <month>July</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <abstract><p>This document updates RFC 1035 by constraining the allowed value of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum of one, and it specifies the required behavior when values that are not allowed are encountered.</p></abstract>
        <draft>draft-ietf-dnsop-qdcount-is-one-04</draft>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9619</errata-url>
        <doi>10.17487/RFC9619</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9620</doc-id>
        <title>Guidelines for Human Rights Protocol and Architecture Considerations</title>
        <author>
            <name>G. Grover</name>
        </author>
        <author>
            <name>N. ten Oever</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>International human rights</kw>
            <kw>Protocol design</kw>
        </keywords>
        <abstract><p>This document sets guidelines for human rights considerations for developers working on network protocols and architectures, similar to the work done on the guidelines for privacy considerations (RFC 6973). This is an updated version of the guidelines for human rights considerations in RFC 8280.</p><p> This document is a product of the Human Right Protocol Considerations (HRPC) Research Group in the IRTF.</p></abstract>
        <draft>draft-irtf-hrpc-guidelines-21</draft>
        <updates>
            <doc-id>RFC8280</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9620</errata-url>
        <doi>10.17487/RFC9620</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9621</doc-id>
        <title>Architecture and Requirements for Transport Services</title>
        <author>
            <name>T. Pauly</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Trammell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Brunstrom</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>C. S. Perkins</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <abstract><p>This document describes an architecture that exposes transport protocol features to applications for network communication.  The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern.  This API uses Messages for representing data transfer to applications and describes how a Transport Services Implementation can use multiple IP addresses, multiple protocols, and multiple paths and can provide multiple application streams.  This document provides the architecture and requirements.  It defines common terminology and concepts to be used in definitions of a Transport Services API and a Transport Services Implementation.</p></abstract>
        <draft>draft-ietf-taps-arch-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <doi>10.17487/RFC9621</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9622</doc-id>
        <title>An Abstract Application Programming Interface (API) for Transport Services</title>
        <author>
            <name>B. Trammell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Welzl</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Enghardt</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>C. S. Perkins</name>
        </author>
        <author>
            <name>P.S. Tiesel</name>
        </author>
        <author>
            <name>T. Pauly</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>84</page-count>
        <keywords>
            <kw>Happy Eyeballs</kw>
            <kw>Transport Selection</kw>
        </keywords>
        <abstract><p>This document describes an abstract Application Programming Interface (API) to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime.  This API enables faster deployment of new protocols and protocol features without requiring changes to the applications.  The specified API follows the Transport Services Architecture by providing asynchronous, atomic transmission of Messages.  It is intended to replace the BSD Socket API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols.</p></abstract>
        <draft>draft-ietf-taps-interface-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <doi>10.17487/RFC9622</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9623</doc-id>
        <title>Implementing Interfaces to Transport Services</title>
        <author>
            <name>A. Brunstrom</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Pauly</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Enghardt</name>
        </author>
        <author>
            <name>P.S. Tiesel</name>
        </author>
        <author>
            <name>M. Welzl</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <abstract><p>The Transport Services System enables applications to use transport protocols flexibly for network communication and defines a protocol-independent Transport Services Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern.  This document serves as a guide to implementing such a system.</p></abstract>
        <draft>draft-ietf-taps-impl-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>taps</wg_acronym>
        <doi>10.17487/RFC9623</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9624</doc-id>
        <title>EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index Explicit Replication (BIER)</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This document specifies protocols and procedures for forwarding Broadcast, Unknown Unicast, or Multicast (BUM) traffic of Ethernet VPNs (EVPNs) using Bit Index Explicit Replication (BIER).</p></abstract>
        <draft>draft-ietf-bier-evpn-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <doi>10.17487/RFC9624</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9625</doc-id>
        <title>EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding</title>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>63</page-count>
        <keywords>
            <kw>OISM</kw>
            <kw>PEG</kw>
            <kw>MEG</kw>
            <kw>SBD</kw>
        </keywords>
        <abstract><p>Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple segments.  Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone.  Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone.  When a single tenant owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs.  This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant while still making intra-subnet IP multicast traffic appear to be bridged.  These procedures can provide optimal routing of the inter-subnet multicast traffic and do not require any such traffic to egress a given router and then ingress that same router.  These procedures also accommodate IP multicast traffic that originates or is destined to be external to the EVPN domain.</p></abstract>
        <draft>draft-ietf-bess-evpn-irb-mcast-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9625</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9626</doc-id>
        <title>Video Frame Marking RTP Header Extension</title>
        <author>
            <name>M. Zanaty</name>
        </author>
        <author>
            <name>E. Berger</name>
        </author>
        <author>
            <name>S. Nandakumar</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Scalable video</kw>
            <kw>H.264</kw>
            <kw>H.265</kw>
            <kw>VP9</kw>
            <kw>layered video</kw>
        </keywords>
        <abstract><p>This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes.  It is most useful when media is encrypted and essential when the middlebox or node has no access to the media decryption keys.  It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information.</p></abstract>
        <draft>draft-ietf-avtext-framemarking-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9626</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9627</doc-id>
        <title>The Layer Refresh Request (LRR) RTCP Feedback Message</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>D. Hong</name>
        </author>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>S. Holmer</name>
        </author>
        <author>
            <name>M. Flodman</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>RTP</kw>
        </keywords>
        <abstract><p>This memo describes the RTCP Payload-Specific Feedback Message Layer Refresh Request (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream.  This document also defines its use with several RTP payloads for scalable media formats.</p></abstract>
        <draft>draft-ietf-avtext-lrr-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>avtext</wg_acronym>
        <doi>10.17487/RFC9627</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9628</doc-id>
        <title>RTP Payload Format for VP9 Video</title>
        <author>
            <name>J. Uberti</name>
        </author>
        <author>
            <name>S. Holmer</name>
        </author>
        <author>
            <name>M. Flodman</name>
        </author>
        <author>
            <name>D. Hong</name>
        </author>
        <author>
            <name>J. Lennox</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>RTP</kw>
            <kw>VP9</kw>
            <kw>WebM</kw>
        </keywords>
        <abstract><p>This specification describes an RTP payload format for the VP9 video codec.  The payload format has wide applicability as it supports applications from low bitrate peer-to-peer usage to high bitrate video conferences.  It includes provisions for temporal and spatial scalability.</p></abstract>
        <draft>draft-ietf-payload-vp9-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9628</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9629</doc-id>
        <title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>J. Gray</name>
        </author>
        <author>
            <name>T. Okubo</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>kemri</kw>
            <kw>KEMRecipientInfo</kw>
        </keywords>
        <abstract><p>The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms.  In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms.  This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content.  This document updates RFC 5652.</p></abstract>
        <draft>draft-ietf-lamps-cms-kemri-08</draft>
        <updates>
            <doc-id>RFC5652</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9629</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9630</doc-id>
        <title>Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM)</title>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>M. McBride</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>G. Mishra</name>
        </author>
        <author>
            <name>H. Asaeda</name>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Multicast</kw>
            <kw>Telemetry</kw>
        </keywords>
        <abstract><p>This document specifies two solutions to meet the requirements of on-path telemetry for multicast traffic using IOAM.  While IOAM is advantageous for multicast traffic telemetry, some unique challenges are present.  This document provides the solutions based on the IOAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy.</p></abstract>
        <draft>draft-ietf-mboned-multicast-telemetry-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mboned</wg_acronym>
        <doi>10.17487/RFC9630</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9631</doc-id>
        <title>The IPv6 Compact Routing Header (CRH)</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>Y. Kamite</name>
        </author>
        <author>
            <name>A. Alston</name>
        </author>
        <author>
            <name>D. Henriques</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Routing header</kw>
        </keywords>
        <abstract><p>This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Header (CRH). Individually, they are called CRH-16 and CRH-32.</p><p> One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations described in this document can be addressed with Access Control Lists (ACLs). Finally, this document encourages replication of the experiment.</p></abstract>
        <draft>draft-ietf-6man-comp-rtg-hdr-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9631</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9632</doc-id>
        <title>Finding and Using Geofeed Data</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>M. Candela</name>
        </author>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>geolocation</kw>
            <kw>geo-location</kw>
            <kw>RPSL</kw>
            <kw>inetnum</kw>
        </keywords>
        <abstract><p>This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files.  This document obsoletes RFC 9092.</p></abstract>
        <draft>draft-ietf-opsawg-9092-update-11</draft>
        <obsoletes>
            <doc-id>RFC9092</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9632</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9633</doc-id>
        <title>Deterministic Networking (DetNet) YANG Data Model</title>
        <author>
            <name>X. Geng</name>
        </author>
        <author>
            <name>Y. Ryoo</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>126</page-count>
        <abstract><p>This document contains the specification for the Deterministic Networking (DetNet) YANG data model for configuration and operational data for DetNet flows. The model allows the provisioning of an end-to-end DetNet service on devices along the path without depending on any signaling protocol. It also specifies operational status for flows.</p><p> The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA).</p></abstract>
        <draft>draft-ietf-detnet-yang-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9633</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9634</doc-id>
        <title>Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>DetNet</kw>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane.</p></abstract>
        <draft>draft-ietf-detnet-ip-oam-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>detnet</wg_acronym>
        <doi>10.17487/RFC9634</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9635</doc-id>
        <title>Grant Negotiation and Authorization Protocol (GNAP)</title>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Imbault</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>187</page-count>
        <keywords>
            <kw>authentication</kw>
            <kw>delegation</kw>
            <kw>security</kw>
        </keywords>
        <abstract><p>The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software.  This delegation can include access to a set of APIs as well as subject information passed directly to the software.</p></abstract>
        <draft>draft-ietf-gnap-core-protocol-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>gnap</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9635</errata-url>
        <doi>10.17487/RFC9635</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9636</doc-id>
        <title>The Time Zone Information Format (TZif)</title>
        <author>
            <name>A. Olson</name>
        </author>
        <author>
            <name>P. Eggert</name>
        </author>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>45</page-count>
        <keywords>
            <kw>time zone</kw>
            <kw>tzdata</kw>
            <kw>tzif</kw>
        </keywords>
        <abstract><p>This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.</p><p> This document replaces and obsoletes RFC 8536.</p></abstract>
        <draft>draft-murchison-rfc8536bis-15</draft>
        <obsoletes>
            <doc-id>RFC8536</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9636</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9637</doc-id>
        <title>Expanding the IPv6 Documentation Space</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>N. Buraglio</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <abstract><p>The document describes the reservation of an additional IPv6 address prefix for use in documentation.  This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix.  The addition of a /20 prefix allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks.</p></abstract>
        <draft>draft-ietf-v6ops-rfc3849-update-05</draft>
        <updates>
            <doc-id>RFC3849</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC9637</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9638</doc-id>
        <title>Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations</title>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Encapsulation</kw>
            <kw>NVE</kw>
            <kw>Geneve</kw>
            <kw>GUE</kw>
            <kw>VXLAN-GPE</kw>
        </keywords>
        <abstract><p>The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 Working Group starting from the output of the NVO3 encapsulation Design Team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats.</p><p> There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, Operations, Administration, and Maintenance (OAM) functions such as path MTU discovery become challenging with multiple encapsulations along the data path.</p><p> Based on these considerations, the NVO3 Working Group determined that Generic Network Virtualization Encapsulation (Geneve) with a few modifications is the common encapsulation. This document provides more details, particularly in Section 7.</p></abstract>
        <draft>draft-ietf-nvo3-encap-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC9638</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9639</doc-id>
        <title>Free Lossless Audio Codec (FLAC)</title>
        <author>
            <name>M.Q.C. van Beurden</name>
        </author>
        <author>
            <name>A. Weaver</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>75</page-count>
        <keywords>
            <kw>free</kw>
            <kw>lossless</kw>
            <kw>audio</kw>
            <kw>codec</kw>
            <kw>encoder</kw>
            <kw>decoder</kw>
            <kw>compression</kw>
            <kw>compressor</kw>
            <kw>archival</kw>
            <kw>archive</kw>
            <kw>archiving</kw>
            <kw>backup</kw>
            <kw>music</kw>
        </keywords>
        <abstract><p>This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset.  FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals.  It does this losslessly, i.e., it does so without losing information.  FLAC is free in the sense that its specification is open and its reference implementation is open source.  Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources.  Decoding of FLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic.</p></abstract>
        <draft>draft-ietf-cellar-flac-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cellar</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9639</errata-url>
        <doi>10.17487/RFC9639</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9640</doc-id>
        <title>YANG Data Types and Groupings for Cryptography</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <abstract><p>This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications.</p></abstract>
        <draft>draft-ietf-netconf-crypto-types-34</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC9640</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9641</doc-id>
        <title>A YANG Data Model for a Truststore</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>This document presents a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust.  Notifications are sent when certificates are about to expire.</p></abstract>
        <draft>draft-ietf-netconf-trust-anchors-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC9641</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9642</doc-id>
        <title>A YANG Data Model for a Keystore</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>This document presents a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys.  The secret value for both key types may be encrypted or hidden.  Asymmetric keys may be associated with certificates.  Notifications are sent when certificates are about to expire.</p></abstract>
        <draft>draft-ietf-netconf-keystore-35</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9642</errata-url>
        <doi>10.17487/RFC9642</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9643</doc-id>
        <title>YANG Groupings for TCP Clients and TCP Servers</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>M. Scharf</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>This document presents three YANG 1.1 modules to support the configuration of TCP clients and TCP servers.  The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies.  The data models defined by these modules may be used directly (e.g., to define a specific TCP client or TCP server) or in conjunction with the configuration defined for higher level protocols that depend on TCP (e.g., SSH, TLS, etc.).  Examples of higher level protocol configuration designed to be used in conjunction with this configuration are in RFCs 9644 and 9645.</p></abstract>
        <draft>draft-ietf-netconf-tcp-client-server-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC9643</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9644</doc-id>
        <title>YANG Groupings for SSH Clients and SSH Servers</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>64</page-count>
        <abstract><p>This document presents three IETF-defined YANG modules and a script used to create four supporting IANA modules.</p><p> The three IETF modules are ietf-ssh-common, ietf-ssh-client, and ietf-ssh-server. The "ietf-ssh-client" and "ietf-ssh-server" modules are the primary productions of this work, supporting the configuration and monitoring of Secure Shell (SSH) clients and servers.</p><p> The four IANA modules are iana-ssh-encryption-algs, iana-ssh-key-exchange-algs, iana-ssh-mac-algs, and iana-ssh-public-key-algs. These modules each define YANG enumerations providing support for an IANA-maintained algorithm registry.</p></abstract>
        <draft>draft-ietf-netconf-ssh-client-server-40</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9644</errata-url>
        <doi>10.17487/RFC9644</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9645</doc-id>
        <title>YANG Groupings for TLS Clients and TLS Servers</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>IETF</kw>
        </keywords>
        <abstract><p>This document presents four YANG 1.1 modules -- three IETF modules and one supporting IANA module.</p><p> The three IETF modules are "ietf-tls-common", "ietf-tls-client", and "ietf-tls-server". The "ietf-tls-client" and "ietf-tls-server" modules are the primary productions of this work, supporting the configuration and monitoring of TLS clients and servers.</p><p> The IANA module is "iana-tls-cipher-suite-algs". This module defines YANG enumerations that provide support for an IANA-maintained algorithm registry.</p></abstract>
        <draft>draft-ietf-netconf-tls-client-server-41</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9645</errata-url>
        <doi>10.17487/RFC9645</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9646</doc-id>
        <title>Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Request</title>
        <author>
            <name>K. Watsen</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>zerotouch</kw>
            <kw>bootstrap</kw>
            <kw>sztp</kw>
            <kw>ztp</kw>
            <kw>csr</kw>
            <kw>pkcs#10</kw>
            <kw>p10</kw>
            <kw>p10cr</kw>
            <kw>cmc</kw>
            <kw>cmp</kw>
        </keywords>
        <abstract><p>This document extends the input to the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., a Local Device Identifier (LDevID) from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply.</p></abstract>
        <draft>draft-ietf-netconf-sztp-csr-14</draft>
        <updates>
            <doc-id>RFC8572</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netconf</wg_acronym>
        <doi>10.17487/RFC9646</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9647</doc-id>
        <title>A YANG Data Model for Babel</title>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>B. Stark</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>babel</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a data model for the Babel routing protocol.  The data model is defined using the YANG data modeling language.</p></abstract>
        <draft>draft-ietf-babel-yang-model-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>babel</wg_acronym>
        <doi>10.17487/RFC9647</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9648</doc-id>
        <title>YANG Data Model for TCP</title>
        <author>
            <name>M. Scharf</name>
        </author>
        <author>
            <name>M. Jethanandani</name>
        </author>
        <author>
            <name>V. Murgai</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document specifies a minimal YANG data model for TCP on devices that are configured and managed by network management protocols.  The YANG data model defines a container for all TCP connections and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters.  The model also includes basic TCP statistics.  The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342).</p></abstract>
        <draft>draft-ietf-tcpm-yang-tcp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tcpm</wg_acronym>
        <doi>10.17487/RFC9648</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9649</doc-id>
        <title>WebP Image Format</title>
        <author>
            <name>J. Zern</name>
        </author>
        <author>
            <name>P. Massimino</name>
        </author>
        <author>
            <name>J. Alakuijala</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>VP8</kw>
            <kw>WebP</kw>
        </keywords>
        <abstract><p>This document defines the WebP image format and registers a media type supporting its use.</p></abstract>
        <draft>draft-zern-webp-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9649</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9650</doc-id>
        <title>Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values</title>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>3</page-count>
        <abstract><p>RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines an IANA registry called "IS-IS Neighbor Link-Attribute Bit Values".  This document changes the registration procedure for that registry from "Standards Action" to "Expert Review".  This document updates RFC 5029.</p></abstract>
        <draft>draft-ietf-lsr-labv-registration-03</draft>
        <updates>
            <doc-id>RFC5029</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9650</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9651</doc-id>
        <title>Structured Field Values for HTTP</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>P-H. Kamp</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>trailer</kw>
            <kw>header</kw>
        </keywords>
        <abstract><p>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields.</p><p> This document obsoletes RFC 8941.</p></abstract>
        <draft>draft-ietf-httpbis-sfbis-06</draft>
        <obsoletes>
            <doc-id>RFC8941</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9651</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9652</doc-id>
        <title>The Link-Template HTTP Header Field</title>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>link relation</kw>
        </keywords>
        <abstract><p>This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources so that new links can be generated.</p></abstract>
        <draft>draft-ietf-httpapi-link-template-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpapi</wg_acronym>
        <doi>10.17487/RFC9652</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9653</doc-id>
        <title>Zero Checksum for the Stream Control Transmission Protocol</title>
        <author>
            <name>M. Tüxen</name>
        </author>
        <author>
            <name>V. Boivie</name>
        </author>
        <author>
            <name>F. Castelli</name>
        </author>
        <author>
            <name>R. Jesup</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. If another method used by SCTP already provides the same or a higher level of data integrity, computing this checksum does not provide any additional protection but does consume computing resources.</p><p> This document provides a simple extension allowing SCTP to save these computing resources by using zero as the checksum in a backwards-compatible way. It also defines how this feature can be used when SCTP packets are encapsulated in Datagram Transport Layer Security (DTLS) packets.</p></abstract>
        <draft>draft-ietf-tsvwg-sctp-zero-checksum-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>tsvwg</wg_acronym>
        <doi>10.17487/RFC9653</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9654</doc-id>
        <title>Online Certificate Status Protocol (OCSP) Nonce Extension</title>
        <author>
            <name>H. Sharma</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>RFC 8954 imposed size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message.</p><p> Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document also modifies the "Nonce" section of RFC 6960 to clearly define and differentiate the encoding format and values for easier implementation and understanding. This document obsoletes RFC 8954, which includes updated ASN.1 modules for OCSP, and updates RFC 6960.</p></abstract>
        <draft>draft-ietf-lamps-ocsp-nonce-update-11</draft>
        <obsoletes>
            <doc-id>RFC8954</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC6960</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9654</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9655</doc-id>
        <title>Egress Validation in Label Switched Path Ping and Traceroute Mechanisms</title>
        <author>
            <name>D. Rathi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hegde</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Arora</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <author>
            <name>N. Nainar</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>FEC</kw>
            <kw>OAM</kw>
            <kw>OSPF</kw>
            <kw>IS-IS</kw>
            <kw>SPRING</kw>
        </keywords>
        <abstract><p>The MPLS ping and traceroute mechanisms described in RFC 8029 and the related extensions for Segment Routing (SR) defined in RFC 8287 are highly valuable for validating control plane and data plane synchronization. In certain environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A straightforward MPLS ping and traceroute mechanism allows traversal of any path without validation of the control plane state. RFC 8029 supports this mechanism with the Nil Forwarding Equivalence Class (FEC). The procedures outlined in RFC 8029 are primarily applicable when the Nil FEC is used as an intermediate FEC in the FEC stack. However, challenges arise when all labels in the label stack are represented using the Nil FEC.</p><p> This document introduces a new Type-Length-Value (TLV) as an extension to the existing Nil FEC. It describes MPLS ping and traceroute procedures using the Nil FEC with this extension to address and overcome these challenges.</p></abstract>
        <draft>draft-ietf-mpls-egress-tlv-for-nil-fec-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9655</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9656</doc-id>
        <title>A YANG Data Model for Microwave Topology</title>
        <author>
            <name>S. Mansfield</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Ahlberg</name>
        </author>
        <author>
            <name>M. Ye</name>
        </author>
        <author>
            <name>X. Li</name>
        </author>
        <author>
            <name>D. Spreafico</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>39</page-count>
        <keywords>
            <kw>microwave</kw>
            <kw>topology</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model to describe microwave and millimeter-wave radio links in a network topology.</p></abstract>
        <draft>draft-ietf-ccamp-mw-topo-yang-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>ccamp</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9656</errata-url>
        <doi>10.17487/RFC9656</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9657</doc-id>
        <title>Time-Variant Routing (TVR) Use Cases</title>
        <author>
            <name>E. Birrane, III</name>
        </author>
        <author>
            <name>N. Kuhn</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>R. Taylor</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Time-variant</kw>
            <kw>Routing</kw>
            <kw>Mobility</kw>
            <kw>Green computing</kw>
            <kw>Resource management</kw>
        </keywords>
        <abstract><p>This document introduces use cases where Time-Variant Routing (TVR) computations (i.e., routing computations that take into consideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</p></abstract>
        <draft>draft-ietf-tvr-use-cases-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>tvr</wg_acronym>
        <doi>10.17487/RFC9657</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9658</doc-id>
        <title>Multipoint LDP Extensions for Multi-Topology Routing</title>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>M. Mishra</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>A. Gulko</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>MPLS</kw>
            <kw>mLDP</kw>
            <kw>Multi-topology</kw>
        </keywords>
        <abstract><p>Multi-Topology Routing (MTR) is a technology that enables service differentiation within an IP network.  The Flexible Algorithm (FA) is another mechanism for creating a sub-topology within a topology using defined topology constraints and computation algorithms.  In order to deploy Multipoint LDP (mLDP) in a network that supports MTR, FA, or other methods of signaling non-default IGP Algorithms (IPAs), mLDP is required to become topology and algorithm aware.  This document specifies extensions to mLDP to support the use of MTR/IPAs such that, when building multipoint Label Switched Paths (LSPs), the LSPs can follow a particular topology and algorithm.  This document updates RFC 7307 by allocating eight bits from a previously reserved field to be used as the "IPA" field.</p></abstract>
        <draft>draft-ietf-mpls-mldp-multi-topology-09</draft>
        <updates>
            <doc-id>RFC7307</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9658</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9659</doc-id>
        <title>Window Sizing for Zstandard Content Encoding</title>
        <author>
            <name>N. Jaju</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. F. Handte</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>zstd</kw>
            <kw>zstandard</kw>
            <kw>compression</kw>
            <kw>content encoding</kw>
            <kw>content coding</kw>
            <kw>application/zstd</kw>
        </keywords>
        <abstract><p>Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression.  Some browsers and user agents limit window sizes to mitigate memory usage concerns, thereby causing interoperability issues.  This document updates the window size limit in RFC 8878 from a recommendation to a requirement in HTTP contexts.</p></abstract>
        <draft>draft-ietf-httpbis-zstd-window-size-03</draft>
        <updates>
            <doc-id>RFC8878</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9659</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9660</doc-id>
        <title>The DNS Zone Version (ZONEVERSION) Option</title>
        <author>
            <name>H. Salgado</name>
        </author>
        <author>
            <name>M. Vergara</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>zoneversion</kw>
        </keywords>
        <abstract><p>The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The SERIAL field from the Start of Authority (SOA) resource record (RR) is a good example of a zone's version, and it is the only one defined by this specification. Additional version types may be defined by future specifications.</p><p> Including zone version data in a response simplifies and improves the quality of debugging and diagnostics since the version and the DNS answer are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the DNS Name Server Identifier (NSID) option described in RFC 5001.</p></abstract>
        <draft>draft-ietf-dnsop-zoneversion-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9660</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9661</doc-id>
        <title>The JSON Meta Application Protocol (JMAP) for Sieve Scripts</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>September</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
            <kw>Sieve</kw>
        </keywords>
        <abstract><p>This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP).  Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts.</p></abstract>
        <draft>draft-ietf-jmap-sieve-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9661</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9662</doc-id>
        <title>Updates to the Cipher Suites in Secure Syslog</title>
        <author>
            <name>C. Lonvick</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <author>
            <name>J. Salowey</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>syslog</kw>
            <kw>secure syslog</kw>
            <kw>TLS_RSA_WITH_AES_128_CBC_SHA</kw>
            <kw>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</kw>
            <kw>DTLS</kw>
            <kw>TLS</kw>
            <kw>cipher suite</kw>
        </keywords>
        <abstract><p>RFCs 5425 and 6012 describe using TLS and DTLS to securely transport syslog messages.  This document updates the cipher suites required by RFC 5245 (TLS Transport Mapping for Syslog) and RFC 6012 (DTLS Transport Mapping for Syslog).  It also updates the protocol recommended by RFC 6012 for secure datagram transport.</p></abstract>
        <draft>draft-ietf-uta-ciphersuites-in-sec-syslog-07</draft>
        <updates>
            <doc-id>RFC5425</doc-id>
            <doc-id>RFC6012</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>uta</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9662</errata-url>
        <doi>10.17487/RFC9662</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9663</doc-id>
        <title>Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks</title>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>J. Linkova</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Ma</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>SLAAC</kw>
            <kw>DHCPv6-PD</kw>
        </keywords>
        <abstract><p>This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415.</p></abstract>
        <draft>draft-ietf-v6ops-dhcp-pd-per-device-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC9663</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9664</doc-id>
        <title>An EDNS(0) Option to Negotiate Leases on DNS Updates</title>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>DNS Update</kw>
        </keywords>
        <abstract><p>This document describes an EDNS(0) option that can be used between DNS Update Requesters and authoritative DNS servers to include a lifetime (lease duration) in a DNS Update or DNS Update Response, allowing a server to garbage collect stale Resource Records that have been added by DNS Updates if they are not renewed.</p></abstract>
        <draft>draft-ietf-dnssd-update-lease-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC9664</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9665</doc-id>
        <title>Service Registration Protocol for DNS-Based Service Discovery</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Multicast DNS</kw>
            <kw>DNS-Based Service Discovery</kw>
            <kw>DNS Update</kw>
            <kw>SIG(0)</kw>
        </keywords>
        <abstract><p>The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets.  This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks.  DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations.</p></abstract>
        <draft>draft-ietf-dnssd-srp-25</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dnssd</wg_acronym>
        <doi>10.17487/RFC9665</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9666</doc-id>
        <title>Area Proxy for IS-IS</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>S. Chen</name>
        </author>
        <author>
            <name>V. Ilangovan</name>
        </author>
        <author>
            <name>G. Mishra</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>datacenter</kw>
            <kw>IGP</kw>
            <kw>routing</kw>
            <kw>topology</kw>
            <kw>level</kw>
            <kw>abstraction</kw>
            <kw>IS-IS</kw>
            <kw>proxy</kw>
        </keywords>
        <abstract><p>Link-state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, thereby leading to scaling issues.</p><p> To avoid such issues, this document discusses extensions to the IS-IS routing protocol that allow Level 1 (L1) areas to provide transit but only inject an abstraction of the Level 1 topology into Level 2 (L2). Each Level 1 area is represented as a single Level 2 node, thereby enabling a greater scale.</p></abstract>
        <draft>draft-ietf-lsr-isis-area-proxy-12</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9666</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9667</doc-id>
        <title>Dynamic Flooding on Dense Graphs</title>
        <author>
            <name>T. Li</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
            <title>Editor</title>
        </author>
        <author>
            <name>H. Chen</name>
        </author>
        <author>
            <name>L. Jalil</name>
        </author>
        <author>
            <name>S. Dontula</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>datacenter</kw>
            <kw>IGP</kw>
            <kw>routing</kw>
            <kw>flooding</kw>
            <kw>dense</kw>
            <kw>graph</kw>
            <kw>topology</kw>
        </keywords>
        <abstract><p>Routing with link-state protocols in dense network topologies can result in suboptimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense.</p><p> This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document.</p></abstract>
        <draft>draft-ietf-lsr-dynamic-flooding-18</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9667</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9668</doc-id>
        <title>Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)</title>
        <author>
            <name>F. Palombini</name>
        </author>
        <author>
            <name>M. Tiloca</name>
        </author>
        <author>
            <name>R. Höglund</name>
        </author>
        <author>
            <name>S. Hristozov</name>
        </author>
        <author>
            <name>G. Selander</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>security</kw>
            <kw>key agreement</kw>
            <kw>secure communication</kw>
            <kw>constrained environments</kw>
            <kw>AKE</kw>
            <kw>lightweight authenticated key exchange</kw>
            <kw>IoT security</kw>
        </keywords>
        <abstract><p>The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE).  This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction.  This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context.</p></abstract>
        <draft>draft-ietf-core-oscore-edhoc-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>core</wg_acronym>
        <doi>10.17487/RFC9668</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9669</doc-id>
        <title>BPF Instruction Set Architecture (ISA)</title>
        <author>
            <name>D. Thaler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>eBPF</kw>
            <kw>virtual machine</kw>
            <kw>extensibility</kw>
        </keywords>
        <abstract><p>eBPF (which is no longer an acronym for anything), also commonly referred to as BPF, is a technology with origins in the Linux kernel that can run untrusted programs in a privileged context such as an operating system kernel.  This document specifies the BPF instruction set architecture (ISA).</p></abstract>
        <draft>draft-ietf-bpf-isa-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>bpf</wg_acronym>
        <doi>10.17487/RFC9669</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9670</doc-id>
        <title>JSON Meta Application Protocol (JMAP) Sharing</title>
        <author>
            <name>N. Jenkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>JMAP</kw>
            <kw>JSON</kw>
            <kw>sharing</kw>
        </keywords>
        <abstract><p>This document specifies a data model for sharing data between users using the JSON Meta Application Protocol (JMAP).  Future documents can reference this document when defining data types to support a consistent model of sharing.</p></abstract>
        <draft>draft-ietf-jmap-sharing-09</draft>
        <updates>
            <doc-id>RFC8620</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9670</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9671</doc-id>
        <title>Sieve Email Filtering: Extension for Processing Calendar Attachments</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <author>
            <name>R. Signes</name>
        </author>
        <author>
            <name>M. Horsfall</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>Sieve</kw>
        </keywords>
        <abstract><p>This document describes the "processcalendar" extension to the Sieve email filtering language.  The "processcalendar" extension gives Sieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet Mail Extensions (MIME).</p></abstract>
        <draft>draft-ietf-extra-processimip-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9671</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9672</doc-id>
        <title>Transferring Opportunistic Wireless Encryption to the IEEE 802.11 Working Group</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>D. Harkins</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>IEEE</kw>
            <kw>OWE</kw>
            <kw>Opportunistic Wireless Encryption</kw>
            <kw>RFC8110</kw>
        </keywords>
        <abstract><p>RFC 8110 describes Opportunistic Wireless Encryption (OWE), a mode that allows unauthenticated clients to connect to a network using encrypted traffic. This document transfers the ongoing maintenance and further development of the protocol to the IEEE 802.11 Working Group.</p><p> This document updates RFC 8110 by noting that future work on the protocol described therein will occur in the IEEE 802.11 Working Group.</p></abstract>
        <draft>draft-wkumari-rfc8110-to-ieee-02</draft>
        <updates>
            <doc-id>RFC8110</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9672</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9673</doc-id>
        <title>IPv6 Hop-by-Hop Options Processing Procedures</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <abstract><p>This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts.  It modifies the procedures specified in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts.  This document updates RFC 8200.</p></abstract>
        <draft>draft-ietf-6man-hbh-processing-20</draft>
        <updates>
            <doc-id>RFC8200</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9673</errata-url>
        <doi>10.17487/RFC9673</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9674</doc-id>
        <title>Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP)</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>same-origin</kw>
            <kw>RPKI</kw>
            <kw>RRDP</kw>
        </keywords>
        <abstract><p>This document describes a Same-Origin Policy (SOP) requirement for Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) servers and clients.  Application of a SOP in RRDP client/server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors.  This document updates RFC 8182.</p></abstract>
        <draft>draft-ietf-sidrops-rrdp-same-origin-04</draft>
        <updates>
            <doc-id>RFC8182</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9674</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9675</doc-id>
        <title>Delay-Tolerant Networking Management Architecture (DTNMA)</title>
        <author>
            <name>E. Birrane, III</name>
        </author>
        <author>
            <name>S. Heiner</name>
        </author>
        <author>
            <name>E. Annis</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract><p>The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices.</p><p> This document describes a DTN Management Architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over unidirectional links and other places where BP is the preferred transport.</p></abstract>
        <draft>draft-ietf-dtn-dtnma-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <doi>10.17487/RFC9675</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9676</doc-id>
        <title>LEX: A Uniform Resource Name (URN) Namespace for Sources of Law</title>
        <author>
            <name>P. Spinosa</name>
        </author>
        <author>
            <name>E. Francesconi</name>
        </author>
        <author>
            <name>C. Lupo</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>42</page-count>
        <keywords>
            <kw>identifier for legal documents</kw>
            <kw>legislation</kw>
            <kw>case law</kw>
            <kw>administrative acts</kw>
        </keywords>
        <abstract><p>This document describes LEX, a Uniform Resource Name (URN) namespace identifier that identifies, names, assigns, and manages persistent resources in the legal domain. This specification allows adoption of a common convention by multiple jurisdictions to facilitate ease of reference and access to resources in the legal domain.</p><p> This specification is an Independent Submission to the RFC Series. It is not a standard and does not have the consensus of the IETF.</p></abstract>
        <draft>draft-spinosa-urn-lex-24</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9676</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9677</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials</title>
        <author>
            <name>F. Fieau</name>
        </author>
        <author>
            <name>E. Stephan</name>
        </author>
        <author>
            <name>G. Bichot</name>
        </author>
        <author>
            <name>C. Neumann</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The delivery of content over HTTPS involving multiple Content Delivery Networks (CDNs) raises credential management issues.  This document defines metadata in the Content Delivery Network Interconnection (CDNI) Control and Metadata interface to set up HTTPS delegation using delegated credentials from an upstream CDN (uCDN) to a downstream CDN (dCDN).</p></abstract>
        <draft>draft-ietf-cdni-https-delegation-subcerts-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC9677</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9678</doc-id>
        <title>Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>K. Norrman</name>
        </author>
        <author>
            <name>J. Preuß Mattsson</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>EAP</kw>
            <kw>AKA</kw>
            <kw>AKA'</kw>
            <kw>EAP-AKA'</kw>
            <kw>EAP-AKA' FS</kw>
            <kw>3GPP</kw>
        </keywords>
        <abstract><p>This document updates RFC 9048, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional extension providing ephemeral key exchange.  The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'.  This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past.  In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale pervasive monitoring) against future sessions.  This forces attackers to use active attacks instead.</p></abstract>
        <draft>draft-ietf-emu-aka-pfs-12</draft>
        <updates>
            <doc-id>RFC5448</doc-id>
            <doc-id>RFC9048</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>emu</wg_acronym>
        <doi>10.17487/RFC9678</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9679</doc-id>
        <title>CBOR Object Signing and Encryption (COSE) Key Thumbprint</title>
        <author>
            <name>K. Isobe</name>
        </author>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>O. Steele</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key.  It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence.  The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key.</p></abstract>
        <draft>draft-ietf-cose-key-thumbprint-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>cose</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9679</errata-url>
        <doi>10.17487/RFC9679</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9680</doc-id>
        <title>Antitrust Guidelines for IETF Participants</title>
        <author>
            <name>J. Halpern</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Daley</name>
        </author>
        <date>
            <month>October</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>anticompetitive</kw>
            <kw>competition law</kw>
            <kw>policy</kw>
            <kw>compliance</kw>
            <kw>recommendations</kw>
        </keywords>
        <abstract><p>This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities.</p></abstract>
        <draft>draft-halpern-gendispatch-antitrust-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9680</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9681</doc-id>
        <title>IS-IS Fast Flooding</title>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>G. Solignac</name>
        </author>
        <author>
            <name>M. Karasek</name>
        </author>
        <author>
            <name>G. Van de Velde</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>LSP</kw>
            <kw>congestion</kw>
            <kw>flow control</kw>
            <kw>scale</kw>
            <kw>performance</kw>
            <kw>IS-S</kw>
            <kw>flooding</kw>
        </keywords>
        <abstract><p>Current Link State PDU flooding rates are much slower than what modern networks can support.  The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals.  This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding.  It also defines protocol extensions relevant to faster flooding.</p></abstract>
        <draft>draft-ietf-lsr-isis-fast-flooding-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9681</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9682</doc-id>
        <title>Updates to the Concise Data Definition Language (CDDL) Grammar</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Concise Data Definition Language</kw>
        </keywords>
        <abstract><p>The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON.</p><p> This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL.</p></abstract>
        <draft>draft-ietf-cbor-update-8610-grammar-06</draft>
        <updates>
            <doc-id>RFC8610</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC9682</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9683</doc-id>
        <title>Remote Integrity Verification of Network Devices Containing Trusted Platform Modules</title>
        <author>
            <name>G. C. Fedorkow</name>
            <title>Editor</title>
        </author>
        <author>
            <name>E. Voit</name>
        </author>
        <author>
            <name>J. Fitzgerald-McKay</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Attestation</kw>
            <kw>TPM</kw>
        </keywords>
        <abstract><p>This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs.</p></abstract>
        <draft>draft-ietf-rats-tpm-based-network-device-attest-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>rats</wg_acronym>
        <doi>10.17487/RFC9683</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9684</doc-id>
        <title>A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)</title>
        <author>
            <name>H. Birkholz</name>
        </author>
        <author>
            <name>M. Eckel</name>
        </author>
        <author>
            <name>S. Bhandari</name>
        </author>
        <author>
            <name>E. Voit</name>
        </author>
        <author>
            <name>B. Sulzen</name>
        </author>
        <author>
            <name>L. Xia</name>
        </author>
        <author>
            <name>T. Laffey</name>
        </author>
        <author>
            <name>G. C. Fedorkow</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>53</page-count>
        <abstract><p>This document defines the YANG Remote Procedure Calls (RPCs) and configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in RFC 9683 "TPM-based Network Device Remote Integrity Verification".  Complementary measurement logs originating from one or more Roots of Trust for Measurement (RTMs) are also provided by the YANG RPCs.  The defined module requires the inclusion of the following in the device components of the composite device on which the YANG server is running: at least one Trusted Platform Module (TPM) of either version 1.2 or 2.0 as well as a corresponding TPM Software Stack (TSS), or an equivalent hardware implementation that includes the protected capabilities as provided by TPMs as well as a corresponding software stack.</p></abstract>
        <draft>draft-ietf-rats-yang-tpm-charra-23</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>rats</wg_acronym>
        <doi>10.17487/RFC9684</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9685</doc-id>
        <title>Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses</title>
        <author>
            <name>P. Thubert</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <keywords>
            <kw>6lo</kw>
            <kw>6LoWPAN</kw>
            <kw>RPL</kw>
            <kw>Wi-SUN</kw>
        </keywords>
        <abstract><p>This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (specified in RFCs 4861 and 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address.  This document also updates the Routing Protocol for Low-Power and Lossy Networks (RPL) (specified in RFCs 6550 and 6553) to add a new Non-Storing multicast mode and new support for anycast addresses in Storing and Non-Storing modes.  This document extends RFC 9010 to enable a 6LoWPAN Router (6LR) to inject the anycast and multicast addresses in RPL.</p></abstract>
        <draft>draft-ietf-6lo-multicast-registration-19</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
            <doc-id>RFC6550</doc-id>
            <doc-id>RFC6553</doc-id>
            <doc-id>RFC8505</doc-id>
            <doc-id>RFC9010</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6lo</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9685</errata-url>
        <doi>10.17487/RFC9685</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9686</doc-id>
        <title>Registering Self-Generated IPv6 Addresses Using DHCPv6</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>S. Krishnan</name>
        </author>
        <author>
            <name>R. Asati</name>
        </author>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <author>
            <name>S. Jiang</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>DHCPv6</kw>
            <kw>IPv6</kw>
            <kw>SLAAC</kw>
        </keywords>
        <abstract><p>This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses.</p></abstract>
        <draft>draft-ietf-dhc-addr-notification-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dhc</wg_acronym>
        <doi>10.17487/RFC9686</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9687</doc-id>
        <title>Border Gateway Protocol 4 (BGP-4) Send Hold Timer</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>B. Cartwright-Cox</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract><p>This document defines the SendHoldTimer, along with the SendHoldTimer_Expires event, for the Border Gateway Protocol (BGP) Finite State Machine (FSM).  Implementation of the SendHoldTimer helps overcome situations where a BGP connection is not terminated after the local system detects that the remote system is not processing BGP messages.  This document specifies that the local system should close the BGP connection and not solely rely on the remote system for connection closure when the SendHoldTimer expires.  This document updates RFC 4271.</p></abstract>
        <draft>draft-ietf-idr-bgp-sendholdtimer-15</draft>
        <updates>
            <doc-id>RFC4271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9687</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9688</doc-id>
        <title>Use of the SHA3 One-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>November</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>HKDF</kw>
            <kw>KMAC128-KDF</kw>
            <kw>KMAC256-KDF</kw>
        </keywords>
        <abstract><p>This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS).  The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or as part of a Key Derivation Function (KDF).</p></abstract>
        <draft>draft-ietf-lamps-cms-sha3-hash-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9688</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9689</doc-id>
        <title>Use Cases for a PCE as a Central Controller (PCECC)</title>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>Q. Zhao</name>
        </author>
        <author>
            <name>Z. Ke</name>
        </author>
        <author>
            <name>B. Khasanov</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>37</page-count>
        <keywords>
            <kw>SDN</kw>
        </keywords>
        <abstract><p>The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. The PCE was developed to derive Traffic Engineering (TE) paths in MPLS networks, which are supplied to the headend of the paths using the Path Computation Element Communication Protocol (PCEP).</p><p> SDN has much broader applicability than signalled MPLS TE networks, and the PCE may be used to determine paths in a range of use cases including static Label-Switched Paths (LSPs), Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. Therefore, it is reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.</p><p> A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions, which are required for the PCECC use cases, are covered in separate documents.</p></abstract>
        <draft>draft-ietf-teas-pcecc-use-cases-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC9689</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9690</doc-id>
        <title>Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>Key Encapsulation Mechanism (KEM)</kw>
            <kw>KEMRecipientInfo</kw>
        </keywords>
        <abstract><p>The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key.  The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006.  This document specifies the conventions for using the RSA-KEM algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629.  This document obsoletes RFC 5990.</p></abstract>
        <draft>draft-ietf-lamps-rfc5990bis-10</draft>
        <obsoletes>
            <doc-id>RFC5990</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9690</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9691</doc-id>
        <title>A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)</title>
        <author>
            <name>C. Martinez</name>
        </author>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>T. Harrison</name>
        </author>
        <author>
            <name>T. Bruijnzeels</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>security</kw>
            <kw>cryptography</kw>
            <kw>X.509</kw>
        </keywords>
        <abstract><p>A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation.  This document defines an RPKI signed object for a Trust Anchor Key (TAK).  A TAK object can be used by a TA to signal to RPs the location(s) of the accompanying CA certificate for the current public key, as well as the successor public key and the location(s) of its CA certificate.  This object helps to support planned key rollovers without impacting RPKI validation.</p></abstract>
        <draft>draft-ietf-sidrops-signed-tal-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9691</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9692</doc-id>
        <title>RIFT: Routing in Fat Trees</title>
        <author>
            <name>T. Przygienda</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Head</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sharma</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>B. Rijsman</name>
        </author>
        <author>
            <name>D. Afanasiev</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>150</page-count>
        <keywords>
            <kw>Routing protocol</kw>
            <kw>IGP</kw>
            <kw>Anisotropic routing</kw>
            <kw>Clos</kw>
            <kw>Fat tree</kw>
            <kw>Cloud</kw>
            <kw>Distance vector</kw>
            <kw>Link state</kw>
            <kw>Optimized flooding</kw>
            <kw>Zeroconf</kw>
            <kw>disaggregation</kw>
            <kw>fabric</kw>
            <kw>ZTP</kw>
            <kw>LIE</kw>
            <kw>TIE</kw>
            <kw>TIDE</kw>
            <kw>TIRE</kw>
            <kw>KV-TIE</kw>
            <kw>multi-plane</kw>
            <kw>ToF</kw>
        </keywords>
        <abstract><p>This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof.  These topologies were initially used within crossbar interconnects and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP fabrics as well.  The protocol specified by this document is optimized towards the minimization of control plane state to support very large substrates as well as the minimization of configuration and operational complexity to allow for a simplified deployment of said topologies.</p></abstract>
        <draft>draft-ietf-rift-rift-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rift</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9692</errata-url>
        <doi>10.17487/RFC9692</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9693</doc-id>
        <title>Benchmarking Methodology for Stateful NATxy Gateways</title>
        <author>
            <name>G. Lencse</name>
        </author>
        <author>
            <name>K. Shima</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>Benchmarking</kw>
            <kw>Stateful NATxy</kw>
            <kw>Measurement Procedure</kw>
            <kw>Throughput</kw>
            <kw>Frame Loss Rate</kw>
            <kw>Latency</kw>
            <kw>PDV</kw>
        </keywords>
        <abstract><p>RFC 2544 defines a benchmarking methodology for network interconnect devices.  RFC 5180 addresses IPv6 specificities, and it also provides a technology update but excludes IPv6 transition technologies.  RFC 8219 addresses IPv6 transition technologies, including stateful NAT64.  However, none of them discuss how to apply pseudorandom port numbers from RFC 4814 to any stateful NATxy (such as NAT44, NAT64, and NAT66) technologies.  This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem.  It recommends a solution that limits the port number ranges and uses two test phases (phase 1 and phase 2).  This document shows how the classic performance measurement procedures (e.g., throughput, frame loss rate, latency, etc.) can be carried out.  New performance metrics and measurement procedures are also defined for measuring the maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity.</p></abstract>
        <draft>draft-ietf-bmwg-benchmarking-stateful-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>bmwg</wg_acronym>
        <doi>10.17487/RFC9693</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9694</doc-id>
        <title>Guidelines for the Definition of New Top-Level Media Types</title>
        <author>
            <name>M.J. Dürst</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>Media Type</kw>
            <kw>Top-Level</kw>
        </keywords>
        <abstract><p>This document defines best practices for defining new top-level media types.  It also introduces a registry for top-level media types, and contains a short history of top-level media types.  It updates RFC 6838.</p></abstract>
        <draft>draft-ietf-mediaman-toplevel-06</draft>
        <updates>
            <doc-id>RFC6838</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0013</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mediaman</wg_acronym>
        <doi>10.17487/RFC9694</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9695</doc-id>
        <title>The 'haptics' Top-Level Media Type</title>
        <author>
            <name>Y. K. Muthusamy</name>
        </author>
        <author>
            <name>C. Ullrich</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>touch</kw>
            <kw>tactile</kw>
            <kw>vibrotactile</kw>
            <kw>kinesthetic</kw>
        </keywords>
        <abstract><p>This memo registers and documents the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered.  This document also serves as a registration for a set of subtypes, which are representative of some existing subtypes already in use.</p></abstract>
        <draft>draft-ietf-mediaman-haptics-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>mediaman</wg_acronym>
        <doi>10.17487/RFC9695</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9696</doc-id>
        <title>Routing in Fat Trees (RIFT) Applicability and Operational Considerations</title>
        <author>
            <name>Y. Wei</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>D. Afanasiev</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>This document discusses the properties, applicability, and operational considerations of Routing in Fat Trees (RIFT) in different network scenarios with the intention of providing a rough guide on how RIFT can be deployed to simplify routing operations in Clos topologies and their variations.</p></abstract>
        <draft>draft-ietf-rift-applicability-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rift</wg_acronym>
        <doi>10.17487/RFC9696</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9697</doc-id>
        <title>Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>T. de Kock</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>desynchronization</kw>
            <kw>RPKI</kw>
            <kw>RRDP</kw>
        </keywords>
        <abstract><p>This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover.  This document updates RFC 8182.</p></abstract>
        <draft>draft-ietf-sidrops-rrdp-desynchronization-04</draft>
        <updates>
            <doc-id>RFC8182</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9697</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9698</doc-id>
        <title>The JMAPACCESS Extension for IMAP</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <author>
            <name>B. Gondwana</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IMAP</kw>
            <kw>JMAP</kw>
        </keywords>
        <abstract><p>This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via the JSON Meta Application Protocol (JMAP), and how.  It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client.</p></abstract>
        <draft>draft-ietf-extra-jmapaccess-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9698</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9699</doc-id>
        <title>Use Case for an Extended Reality Application on Edge Computing Infrastructure</title>
        <author>
            <name>R. Krishna</name>
        </author>
        <author>
            <name>A. Rahman</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>low-latency</kw>
            <kw>managed-cloud</kw>
            <kw>offload</kw>
        </keywords>
        <abstract><p>This document explores the issues involved in the use of edge computing resources to operationalize a media use case that involves an Extended Reality (XR) application.  In particular, this document discusses an XR application that can run on devices having different form factors (such as different physical sizes and shapes) and needs edge computing resources to mitigate the effect of problems such as the need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices.  This document also discusses the expected behavior of XR applications, which can be used to manage traffic, and the service requirements for XR applications to be able to run on the network.  Network operators who are interested in providing edge computing resources to operationalize the requirements of such applications are the intended audience for this document.</p></abstract>
        <draft>draft-ietf-mops-ar-use-case-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mops</wg_acronym>
        <doi>10.17487/RFC9699</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9700</doc-id>
        <title>Best Current Practice for OAuth 2.0 Security</title>
        <author>
            <name>T. Lodderstedt</name>
        </author>
        <author>
            <name>J. Bradley</name>
        </author>
        <author>
            <name>A. Labunets</name>
        </author>
        <author>
            <name>D. Fett</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>46</page-count>
        <keywords>
            <kw>threat model</kw>
            <kw>attacks</kw>
            <kw>mitigations</kw>
        </keywords>
        <abstract><p>This document describes best current security practice for OAuth 2.0.  It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.  Further, it deprecates some modes of operation that are deemed less secure or even insecure.</p></abstract>
        <draft>draft-ietf-oauth-security-topics-29</draft>
        <updates>
            <doc-id>RFC6749</doc-id>
            <doc-id>RFC6750</doc-id>
            <doc-id>RFC6819</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0240</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9700</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9701</doc-id>
        <title>JSON Web Token (JWT) Response for OAuth Token Introspection</title>
        <author>
            <name>T. Lodderstedt</name>
            <title>Editor</title>
        </author>
        <author>
            <name>V. Dzhuvinov</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>token introspection</kw>
            <kw>JWT</kw>
            <kw>oauth2</kw>
        </keywords>
        <abstract><p>This specification proposes an additional response secured by JSON Web Token (JWT) for OAuth 2.0 Token Introspection.</p></abstract>
        <draft>draft-ietf-oauth-jwt-introspection-response-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9701</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9702</doc-id>
        <title>YANG Data Model for Maximum Segment Identifier (SID) Depth (MSD) Types and MPLS MSD</title>
        <author>
            <name>Y. Qu</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <author>
            <name>J. Tantsura</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>MSD Types</kw>
        </keywords>
        <abstract><p>This document defines two YANG modules.  The first module is the initial version of the IANA-maintained YANG module for Maximum Segment Identifier (SID) Depth (MSD) Types, which includes identities for both the MPLS data plane and Segment Routing over IPv6 (SRv6) data plane.  The second module augments the IETF MPLS YANG data model to provide support for MPLS MSDs as defined in RFCs 8476 and 8491.</p></abstract>
        <draft>draft-ietf-mpls-msd-yang-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9702</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9703</doc-id>
        <title>Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS Data Plane</title>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>M. Srivastava</name>
        </author>
        <author>
            <name>K. Arora</name>
        </author>
        <author>
            <name>S. Ninan</name>
        </author>
        <author>
            <name>X. Xu</name>
        </author>
        <date>
            <month>December</month>
            <year>2024</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>OAM</kw>
            <kw>EPE</kw>
            <kw>BGP-LS</kw>
            <kw>BGP</kw>
            <kw>SPRING</kw>
            <kw>SDN</kw>
            <kw>SID</kw>
        </keywords>
        <abstract><p>Egress Peer Engineering (EPE) is an application of Segment Routing (SR) that solves the problem of egress peer selection.  The SR-based BGP-EPE solution allows a centralized controller, e.g., a Software-Defined Network (SDN) controller, to program any egress peer.  The EPE solution requires the node or the SDN controller to program 1) the PeerNode Segment Identifier (SID) describing a session between two nodes, 2) the PeerAdj SID describing the link or links that are used by the sessions between peer nodes, and 3) the PeerSet SID describing any connected interface to any peer in the related group.  This document provides new sub-TLVs for EPE-SIDs that are used in the Target FEC Stack TLV (Type 1) in MPLS Ping and Traceroute procedures.</p></abstract>
        <draft>draft-ietf-mpls-sr-epe-oam-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9703</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9704</doc-id>
        <title>Establishing Local DNS Authority in Validated Split-Horizon Environments</title>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>K. Smith</name>
        </author>
        <author>
            <name>B. Schwartz</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <abstract><p>When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver.  DNS clients that are not configured to use this resolver by default can use it for these specific domains only.  This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains.</p></abstract>
        <draft>draft-ietf-add-split-horizon-authority-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>add</wg_acronym>
        <doi>10.17487/RFC9704</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9705</doc-id>
        <title>Refresh-Interval Independent RSVP Fast Reroute Facility Protection</title>
        <author>
            <name>C. Ramachandran</name>
        </author>
        <author>
            <name>T. Saad</name>
        </author>
        <author>
            <name>D. Pacella</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>ri-rsvp-frr</kw>
            <kw>RI-RSVP-FRR</kw>
        </keywords>
        <abstract><p>The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090 define two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnels.  Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel.  The many-to-one nature of local repair technique is attractive from a scalability point of view.  This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout, hence, making facility backup method refresh-interval dependent.  The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent, and hence, compatible with the Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC 8370.  Hence, this document updates RFC 4090 in order to support the RI-RSVP capability specified in RFC 8370.</p></abstract>
        <draft>draft-ietf-mpls-ri-rsvp-frr-22</draft>
        <updates>
            <doc-id>RFC4090</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9705</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9706</doc-id>
        <title>TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences</title>
        <author>
            <name>L. Giuliano</name>
        </author>
        <author>
            <name>C. Lenart</name>
        </author>
        <author>
            <name>R. Adam</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>multicast</kw>
            <kw>SSM</kw>
            <kw>AMT</kw>
            <kw>LISP</kw>
            <kw>CDN</kw>
            <kw>PIM-SSM</kw>
        </keywords>
        <abstract><p>As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources.  TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences.  TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure.  In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches.  Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication.</p></abstract>
        <draft>draft-ietf-mops-treedn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>mops</wg_acronym>
        <doi>10.17487/RFC9706</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9707</doc-id>
        <title>Report from the IAB Workshop on Barriers to Internet Access of Services (BIAS)</title>
        <author>
            <name>M. Kühlewind</name>
        </author>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>M. Knodel</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Internet Access</kw>
            <kw>Censorship</kw>
            <kw>Community Networks</kw>
            <kw>digital divide</kw>
        </keywords>
        <abstract><p>The "Barriers to Internet Access of Services (BIAS)" workshop was
convened by the Internet Architecture Board (IAB) from January 15-17,
2024 as a three-day online meeting. Based on the submitted position
papers, the workshop covered three areas of interest: the role of
Community Networks in Internet access of services, reports and
comments on the observed digital divide, and measurements of
censorship and censorship circumvention. This report summarizes the
workshop's discussions and serves as a reference for reports on the
current barriers to Internet access.</p><p> Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report were
expressed during the workshop by participants and do not necessarily
reflect the IAB's views and positions.</p></abstract>
        <draft>draft-iab-bias-workshop-report-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IAB</stream>
        <doi>10.17487/RFC9707</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9708</doc-id>
        <title>Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>digital signature</kw>
            <kw>message content</kw>
        </keywords>
        <abstract><p>This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS).  In addition, the algorithm identifier and public key syntax are provided.  The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.  This document obsoletes RFC 8708.</p></abstract>
        <draft>draft-ietf-lamps-rfc8708bis-03</draft>
        <obsoletes>
            <doc-id>RFC8708</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9708</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9709</doc-id>
        <title>Encryption Key Derivation in the Cryptographic Message Syntax (CMS) Using HKDF with SHA-256</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>content-encryption key</kw>
            <kw>content-authenticated-encryption key</kw>
        </keywords>
        <abstract><p>This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256.  The use of this mechanism provides protection against an attacker that manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier.</p></abstract>
        <draft>draft-ietf-lamps-cms-cek-hkdf-sha256-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9709</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9710</doc-id>
        <title>Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>IPFIX</kw>
            <kw>Operations</kw>
            <kw>Network Providers</kw>
            <kw>Network Managment</kw>
            <kw>Anomaly detection</kw>
            <kw>Telemetry</kw>
        </keywords>
        <abstract><p>This document provides simple fixes to the IANA "IP Flow Information Export (IPFIX) Entities" registry.  Specifically, this document provides updates to fix shortcomings in the description of some Information Elements (IEs), to ensure a consistent structure when citing an existing IANA registry, and to fix broken pointers, orphaned section references, etc.  The updates are also meant to bring some consistency among the entries of the registry.</p></abstract>
        <draft>draft-ietf-opsawg-ipfix-fixes-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9710</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9711</doc-id>
        <title>The Entity Attestation Token (EAT)</title>
        <author>
            <name>L. Lundblade</name>
        </author>
        <author>
            <name>G. Mandyam</name>
        </author>
        <author>
            <name>J. O'Donoghue</name>
        </author>
        <author>
            <name>C. Wallace</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>85</page-count>
        <keywords>
            <kw>signing</kw>
            <kw>attestation</kw>
            <kw>cbor</kw>
        </keywords>
        <abstract><p>An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity.</p><p> An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims.</p></abstract>
        <draft>draft-ietf-rats-eat-31</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>rats</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9711</errata-url>
        <doi>10.17487/RFC9711</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9712</doc-id>
        <title>IETF Meeting Venue Requirements Review</title>
        <author>
            <name>J. Daley</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>IETF region</kw>
            <kw>Exploratory meeting</kw>
        </keywords>
        <abstract><p>Following a review of the IETF meeting venue requirements, this document updates RFC 8718 ("IETF Plenary Meeting Venue Selection Process"), clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and specifies a replacement exploratory meeting process, thereby updating RFC 8719 ("High-Level Guidance for the Meeting Policy of the IETF").</p></abstract>
        <draft>draft-daley-gendispatch-venue-requirements-03</draft>
        <updates>
            <doc-id>RFC8718</doc-id>
            <doc-id>RFC8719</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0226</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9712</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9713</doc-id>
        <title>Bundle Protocol Version 7 Administrative Record Types Registry</title>
        <author>
            <name>B. Sipos</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>DTN</kw>
        </keywords>
        <abstract><p>This document updates RFC 9171 to clarify that Bundle Protocol Version 7 agents are expected to use the IANA "Bundle Administrative Record Types" registry to identify and document administrative record types.  This document also designates code points for Private and Experimental Use.</p></abstract>
        <draft>draft-ietf-dtn-bpv7-admin-iana-04</draft>
        <updates>
            <doc-id>RFC9171</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <doi>10.17487/RFC9713</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9714</doc-id>
        <title>Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method</title>
        <author>
            <name>W. Cheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>X. Min</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Zhou</name>
        </author>
        <author>
            <name>J. Dai</name>
        </author>
        <author>
            <name>Y. Peleg</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>Flow-ID Label Indicator</kw>
            <kw>Flow-ID Label</kw>
        </keywords>
        <abstract><p>This document defines the encapsulation for MPLS performance
measurement with the Alternate-Marking Method, which performs
flow-based packet loss, delay, and jitter measurements on MPLS
traffic.</p></abstract>
        <draft>draft-ietf-mpls-inband-pm-encapsulation-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9714</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9715</doc-id>
        <title>IP Fragmentation Avoidance in DNS over UDP</title>
        <author>
            <name>K. Fujiwara</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>IP Fragmentation</kw>
            <kw>attack</kw>
        </keywords>
        <abstract><p>The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server.  Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols.  It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary.  This document describes techniques to avoid IP fragmentation in DNS.</p></abstract>
        <draft>draft-ietf-dnsop-avoid-fragmentation-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9715</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9716</doc-id>
        <title>Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks</title>
        <author>
            <name>S. Hegde</name>
        </author>
        <author>
            <name>K. Arora</name>
        </author>
        <author>
            <name>M. Srivastava</name>
        </author>
        <author>
            <name>S. Ninan</name>
        </author>
        <author>
            <name>N. Kumar</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>OAM</kw>
            <kw>EPE</kw>
            <kw>BGP-LS</kw>
            <kw>BGP</kw>
            <kw>SPRING</kw>
            <kw>SDN</kw>
        </keywords>
        <abstract><p>The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane.  A Segment Routing over MPLS (SR-MPLS) network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization.  It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains.  This document outlines mechanisms to enable efficient LSP ping and traceroute procedures in inter-AS and inter-domain SR-MPLS networks.  This is achieved through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes.</p></abstract>
        <draft>draft-ietf-mpls-spring-inter-domain-oam-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9716</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9717</doc-id>
        <title>A Routing Architecture for Satellite Networks</title>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>IS-IS</kw>
            <kw>MPLS</kw>
            <kw>Segment routing</kw>
        </keywords>
        <abstract><p>Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.</p><p> This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.</p><p> This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.</p></abstract>
        <draft>draft-li-arch-sat-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9717</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9718</doc-id>
        <title>DNSSEC Trust Anchor Publication for the Root Zone</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>J. Schlyter</name>
        </author>
        <author>
            <name>G. Bailey</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>KSK</kw>
        </keywords>
        <abstract><p>The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).</p><p> In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors.</p><p> This document obsoletes RFC 7958.</p></abstract>
        <draft>draft-ietf-dnsop-rfc7958bis-06</draft>
        <obsoletes>
            <doc-id>RFC7958</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>dnsop</wg_acronym>
        <doi>10.17487/RFC9718</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9719</doc-id>
        <title>YANG Data Model for Routing in Fat Trees (RIFT)</title>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>Y. Wei</name>
        </author>
        <author>
            <name>S. Ma</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>B. Rijsman</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>49</page-count>
        <keywords>
            <kw>RIFT</kw>
            <kw>YANG</kw>
        </keywords>
        <abstract><p>This document defines a YANG data model for the configuration and management of the Routing in Fat Trees (RIFT) Protocol.  The model is based on YANG 1.1, which is defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.</p></abstract>
        <draft>draft-ietf-rift-yang-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>rift</wg_acronym>
        <doi>10.17487/RFC9719</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9720</doc-id>
        <title>RFC Formats and Versions</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>H. Flanagan</name>
        </author>
        <date>
            <month>January</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <abstract><p>In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published.</p><p> This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280.</p></abstract>
        <draft>draft-rswg-rfc7990-updates-12</draft>
        <obsoletes>
            <doc-id>RFC7990</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC9280</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>Editorial</stream>
        <doi>10.17487/RFC9720</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9721</doc-id>
        <title>Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)</title>
        <author>
            <name>N. Malhotra</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>A. Pattekar</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <author>
            <name>A. Lingala</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>ES</kw>
            <kw>Ethernet Segment</kw>
            <kw>Peer-Sync-Local</kw>
            <kw>Overlay</kw>
            <kw>NVO</kw>
            <kw>NVO3</kw>
            <kw>RT-2</kw>
            <kw>RT-5</kw>
            <kw>MAC-IP</kw>
        </keywords>
        <abstract><p>This document specifies extensions to the Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and 9135 to enhance the mobility mechanisms for networks based on EVPN-IRB.  The proposed extensions improve the handling of host mobility and duplicate address detection in EVPN-IRB networks to cover a broader set of scenarios where a host's unicast IP address to Media Access Control (MAC) address bindings may change across moves.  These enhancements address limitations in the existing EVPN-IRB mobility procedures by providing more efficient and scalable solutions.  The extensions are backward compatible with existing EVPN-IRB implementations and aim to optimize network performance in scenarios involving frequent IP address mobility.</p></abstract>
        <draft>draft-ietf-bess-evpn-irb-extended-mobility-21</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9721</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9722</doc-id>
        <title>Fast Recovery for EVPN Designated Forwarder Election</title>
        <author>
            <name>P. Brissette</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>LA. Burdet</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>EVPN</kw>
            <kw>Designated Forwarder</kw>
            <kw>Convergence</kw>
            <kw>Recovery</kw>
        </keywords>
        <abstract><p>The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for DF election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein.</p><p> The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via a simple signaling in BGP between the recovered node and each of the other nodes in the multihoming group.</p></abstract>
        <draft>draft-ietf-bess-evpn-fast-df-recovery-12</draft>
        <updates>
            <doc-id>RFC8584</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9722</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9723</doc-id>
        <title>BGP Colored Prefix Routing (CPR) for Services Based on Segment Routing over IPv6 (SRv6)</title>
        <author>
            <name>H. Wang</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <author>
            <name>T. Han</name>
        </author>
        <author>
            <name>R. Chen</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>intent-aware routing</kw>
        </keywords>
        <abstract><p>This document describes a mechanism to advertise IPv6 prefixes in BGP that are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called "Colored Prefix Routing" (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intents. SRv6 services (e.g., SRv6 VPN services) with a specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored Prefixes.</p><p> This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths based on the longest prefix matching of SRv6 Service SIDs to the Colored Prefixes. The existing IPv6 Address Family and Color Extended Community are reused to advertise IPv6 Colored Prefixes without new BGP extensions; thus, this mechanism is easy to interoperate and can be deployed incrementally in multi-Autonomous System (AS) networks that belong to the same trusted domain.</p></abstract>
        <draft>draft-ietf-idr-cpr-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9723</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9724</doc-id>
        <title>State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses</title>
        <author>
            <name>JC. Zúñiga</name>
        </author>
        <author>
            <name>CJ. Bernardos</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Andersdotter</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>privacy</kw>
            <kw>tracking</kw>
            <kw>slap</kw>
            <kw>rcm</kw>
            <kw>802.11bh</kw>
            <kw>802.11bi</kw>
        </keywords>
        <abstract><p>Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking of Internet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses.</p><p> There have been several initiatives within the IETF and the IEEE 802 standards committees to address some of the privacy issues involved. This document provides an overview of these activities to help coordinate standardization activities in these bodies.</p></abstract>
        <draft>draft-ietf-madinas-mac-address-randomization-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>madinas</wg_acronym>
        <doi>10.17487/RFC9724</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9725</doc-id>
        <title>WebRTC-HTTP Ingestion Protocol (WHIP)</title>
        <author>
            <name>S. Garcia Murillo</name>
        </author>
        <author>
            <name>A. Gouaillard</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>28</page-count>
        <keywords>
            <kw>webrtc</kw>
            <kw>streaming</kw>
            <kw>ingest</kw>
        </keywords>
        <abstract><p>This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or Content Delivery Networks (CDNs).</p><p> This document updates RFCs 8840 and 8842.</p></abstract>
        <draft>draft-ietf-wish-whip-16</draft>
        <updates>
            <doc-id>RFC8840</doc-id>
            <doc-id>RFC8842</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>wish</wg_acronym>
        <doi>10.17487/RFC9725</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9726</doc-id>
        <title>Operational Considerations for Use of DNS in Internet of Things (IoT) Devices</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>W. Pan</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>DNS</kw>
            <kw>MUD</kw>
            <kw>round-robin</kw>
            <kw>tailored response</kw>
            <kw>DNSSEC</kw>
            <kw>IoT security</kw>
            <kw>Device Identity</kw>
        </keywords>
        <abstract><p>This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 8520, to control device access.</p><p> Also, this document makes recommendations on when and how to use DNS names in MUD files.</p></abstract>
        <draft>draft-ietf-opsawg-mud-iot-dns-considerations-19</draft>
        <is-also>
            <doc-id>BCP0241</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9726</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9727</doc-id>
        <title>api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs</title>
        <author>
            <name>K. Smith</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>API</kw>
        </keywords>
        <abstract><p>This document defines the "api-catalog" well-known URI and link relation.  It is intended to facilitate automated discovery and usage of published Application Programming Interfaces (APIs).  A request to the api-catalog resource will return a document providing information about, and links to, the Publisher's APIs.</p></abstract>
        <draft>draft-ietf-httpapi-api-catalog-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpapi</wg_acronym>
        <doi>10.17487/RFC9727</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9728</doc-id>
        <title>OAuth 2.0 Protected Resource Metadata</title>
        <author>
            <name>M.B. Jones</name>
        </author>
        <author>
            <name>P. Hunt</name>
        </author>
        <author>
            <name>A. Parecki</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>OAuth</kw>
            <kw>Discovery</kw>
            <kw>Metadata</kw>
            <kw>Discovery Metadata</kw>
            <kw>Configuration Information</kw>
            <kw>Resource Server</kw>
            <kw>Protected Resource</kw>
            <kw>Resource Identifier</kw>
            <kw>JavaScript Object Notation</kw>
            <kw>JSON</kw>
            <kw>JSON Web Token</kw>
            <kw>JWT</kw>
        </keywords>
        <abstract><p>This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource.</p></abstract>
        <draft>draft-ietf-oauth-resource-metadata-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>oauth</wg_acronym>
        <doi>10.17487/RFC9728</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9729</doc-id>
        <title>The Concealed HTTP Authentication Scheme</title>
        <author>
            <name>D. Schinazi</name>
        </author>
        <author>
            <name>D. Oliver</name>
        </author>
        <author>
            <name>J. Hoyland</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>secure</kw>
            <kw>tunnels</kw>
            <kw>masque</kw>
            <kw>http-ng</kw>
        </keywords>
        <abstract><p>Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication.  It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed.  Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication.  This document defines a new non-probeable cryptographic authentication scheme.</p></abstract>
        <draft>draft-ietf-httpbis-unprompted-auth-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpbis</wg_acronym>
        <doi>10.17487/RFC9729</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9730</doc-id>
        <title>Interworking of GMPLS Control and Centralized Controller Systems</title>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>Y. Lin</name>
        </author>
        <author>
            <name>Y. Zhao</name>
        </author>
        <author>
            <name>Y. Xu</name>
        </author>
        <author>
            <name>D. Beller</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>32</page-count>
        <keywords>
            <kw>architecture</kw>
            <kw>ACTN</kw>
            <kw>control plane</kw>
        </keywords>
        <abstract><p>Generalized Multiprotocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing, and signaling in a distributed manner.</p><p> The advancement of software-defined transport networking technology enables a group of NEs to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic-Engineered Networks (ACTN) controller hierarchy, as described in RFC 8453.</p><p> Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than compete. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network.</p></abstract>
        <draft>draft-ietf-teas-gmpls-controller-inter-work-17</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC9730</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9731</doc-id>
        <title>A YANG Data Model for Virtual Network (VN) Operations</title>
        <author>
            <name>Y. Lee</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Dhody</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Ceccarelli</name>
        </author>
        <author>
            <name>I. Bryskin</name>
        </author>
        <author>
            <name>B. Yoon</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>47</page-count>
        <keywords>
            <kw>ACTN</kw>
            <kw>SDN</kw>
            <kw>TE</kw>
        </keywords>
        <abstract><p>A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network.  This document provides a YANG data model generally applicable to any mode of VN operations.  This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453).</p></abstract>
        <draft>draft-ietf-teas-actn-vn-yang-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC9731</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9732</doc-id>
        <title>A Framework for NRP-Based Enhanced Virtual Private Networks</title>
        <author>
            <name>J. Dong</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>T. Miyasaka</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>network slicing</kw>
            <kw>traffic engineering</kw>
            <kw>performance guarantee</kw>
        </keywords>
        <abstract><p>This document describes a framework for Enhanced Virtual Private Networks (VPNs) based on Network Resource Partitions (NRPs) in order to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter).  NRP-based enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs.  Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but it could also be of use in its own right providing enhanced connectivity services between customer sites.  This document also provides an overview of relevant technologies in different network layers and identifies some areas for potential new work.</p></abstract>
        <draft>draft-ietf-teas-enhanced-vpn-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>teas</wg_acronym>
        <doi>10.17487/RFC9732</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9733</doc-id>
        <title>BRSKI with Alternative Enrollment (BRSKI-AE)</title>
        <author>
            <name>D. von Oheimb</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Fries</name>
        </author>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>27</page-count>
        <keywords>
            <kw>BRSKI</kw>
            <kw>IoT</kw>
            <kw>zero-touch onboarding</kw>
            <kw>alternative enrollment protocols</kw>
            <kw>CMP</kw>
            <kw>self-contained signed objects</kw>
            <kw>end-to-end proof of origin</kw>
            <kw>auditable source authentication</kw>
        </keywords>
        <abstract><p>This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative Enrollment (BRSKI-AE).  BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use of Enrollment over Secure Transport (EST).  It supports certificate enrollment protocols such as the Certificate Management Protocol (CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios.  The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols.  This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments.</p></abstract>
        <draft>draft-ietf-anima-brski-ae-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>anima</wg_acronym>
        <doi>10.17487/RFC9733</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9734</doc-id>
        <title>X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>x.509</kw>
            <kw>certificate</kw>
            <kw>extended key usage</kw>
            <kw>eku</kw>
            <kw>instant messaging</kw>
            <kw>im URI</kw>
            <kw>mimi URL</kw>
        </keywords>
        <abstract><p>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  This document defines an Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates</p></abstract>
        <draft>draft-ietf-lamps-im-keyusage-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9734</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9735</doc-id>
        <title>Locator/ID Separation Protocol (LISP) Distinguished Name Encoding</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>L. Iannone</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP).  LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs).  Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.</p></abstract>
        <draft>draft-ietf-lisp-name-encoding-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lisp</wg_acronym>
        <doi>10.17487/RFC9735</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9736</doc-id>
        <title>The BGP Monitoring Protocol (BMP) Peer Up Message Namespace</title>
        <author>
            <name>J. Scudder</name>
        </author>
        <author>
            <name>P. Lucente</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>IDR</kw>
            <kw>GROW</kw>
            <kw>BGP</kw>
            <kw>BMP</kw>
        </keywords>
        <abstract><p>RFC 7854, the BGP Monitoring Protocol (BMP), uses different message types for different purposes. Most of these are structured as Type, Length, Value (TLV). One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol.</p><p> This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFCs 8671 and 9069 by moving defined codepoints into the newly introduced registry. Compliant implementations of RFCs 7854, 8671, and 9069 also comply with this specification.</p></abstract>
        <draft>draft-ietf-grow-bmp-peer-up-05</draft>
        <updates>
            <doc-id>RFC7854</doc-id>
            <doc-id>RFC8671</doc-id>
            <doc-id>RFC9069</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>grow</wg_acronym>
        <doi>10.17487/RFC9736</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9737</doc-id>
        <title>Reporting Errors in NFSv4.2 via LAYOUTRETURN</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <author>
            <name>T. Myklebust</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>The Parallel Network File System (pNFS) allows for a file's metadata and data to be on different servers (i.e., the metadata server (MDS) and the data server (DS)).  When the MDS is restarted, the client can still modify the data file component.  During the recovery phase of startup, the MDS and the DSs work together to recover state.  If the client has not encountered errors with the data files, then the state can be recovered and the resilvering of the data files can be avoided.  With any errors, there is no means by which the client can report errors to the MDS.  As such, the MDS has to assume that a file needs resilvering.  This document presents an extension to RFC 8435 to allow the client to update the metadata via LAYOUTRETURN and avoid the resilvering.</p></abstract>
        <draft>draft-ietf-nfsv4-layrec-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC9737</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9738</doc-id>
        <title>IMAP MESSAGELIMIT Extension</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <author>
            <name>A. P. Achuthan</name>
        </author>
        <author>
            <name>V. Nagulakonda</name>
        </author>
        <author>
            <name>L. Alves</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>The MESSAGELIMIT extension of the Internet Message Access Protocol (RFCs 3501 and 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH, SEARCH, STORE, COPY, or MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command.  This helps servers to control resource usage when performing various IMAP operations.  This helps clients to know the message limit enforced by the corresponding IMAP server and avoid issuing commands that would exceed such limit.</p></abstract>
        <draft>draft-ietf-extra-imap-messagelimit-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9738</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9739</doc-id>
        <title>Protocol Independent Multicast Light (PIM Light)</title>
        <author>
            <name>H. Bidgoli</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <author>
            <name>M. Mishra</name>
        </author>
        <author>
            <name>Z. Zhang</name>
        </author>
        <author>
            <name>M. McBride</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>9</page-count>
        <abstract><p>This document specifies Protocol Independent Multicast Light (PIM Light) and the PIM Light Interface (PLI).  A PLI does not need a PIM Hello message to accept PIM Join/Prune messages, and it can signal multicast states over networks that cannot support full PIM neighbor discovery, such as Bit Index Explicit Replication (BIER) networks that connect two or more PIM domains.  This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers.</p></abstract>
        <draft>draft-ietf-pim-light-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9739</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9740</doc-id>
        <title>New IPFIX Information Elements for TCP Options and IPv6 Extension Headers</title>
        <author>
            <name>M. Boucadair</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>21</page-count>
        <keywords>
            <kw>IPFIX</kw>
        </keywords>
        <abstract><p>This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options.</p></abstract>
        <draft>draft-ietf-opsawg-ipfix-tcpo-v6eh-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9740</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9741</doc-id>
        <title>Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Concise Data Definition Language</kw>
            <kw>Control Operator</kw>
        </keywords>
        <abstract><p>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way.</p><p> The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text.</p></abstract>
        <draft>draft-ietf-cbor-cddl-more-control-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>cbor</wg_acronym>
        <doi>10.17487/RFC9741</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9742</doc-id>
        <title>A YANG Data Model for Syslog Management</title>
        <author>
            <name>J. Clarke</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Jethanandani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Wildes</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Koushik</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <abstract><p>This document defines a YANG data model for the management of a syslog process.  It is intended that this data model be used by vendors who implement syslog collectors in their systems.</p></abstract>
        <draft>draft-ietf-netmod-syslog-model-33</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>netmod</wg_acronym>
        <doi>10.17487/RFC9742</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9743</doc-id>
        <title>Specifying New Congestion Control Algorithms</title>
        <author>
            <name>M. Duke</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Fairhurst</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>23</page-count>
        <keywords>
            <kw>Transport</kw>
            <kw>CC</kw>
        </keywords>
        <abstract><p>RFC 5033 discusses the principles and guidelines for standardizing new congestion control algorithms.  This document obsoletes RFC 5033 to reflect changes in the congestion control landscape by providing a framework for the development and assessment of congestion control mechanisms, promoting stability across diverse network paths.  This document seeks to ensure that proposed congestion control algorithms operate efficiently and without harm when used in the global Internet.  It emphasizes the need for comprehensive testing and validation to prevent adverse interactions with existing flows.</p></abstract>
        <draft>draft-ietf-ccwg-rfc5033bis-08</draft>
        <obsoletes>
            <doc-id>RFC5033</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0133</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>ccwg</wg_acronym>
        <doi>10.17487/RFC9743</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9744</doc-id>
        <title>EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) Service</title>
        <author>
            <name>A. Sajassi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Brissette</name>
        </author>
        <author>
            <name>J. Uttaro</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>EVPN</kw>
            <kw>VPWS</kw>
            <kw>Flexible Cross Connect</kw>
            <kw>FXC</kw>
        </keywords>
        <abstract><p>This document describes a new EVPN Virtual Private Wire Service (VPWS) service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments (ESs) and physical interfaces into a single EVPN-VPWS service tunnel and still providing Single-Active and All-Active multi-homing.  This new service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service.  This document specifies a solution based on extensions to EVPN-VPWS (RFC 8214), which in turn is based on extensions to EVPN (RFC 7432).  Therefore, a thorough understanding of RFCs 7432 and 8214 are prerequisites for this document.</p></abstract>
        <draft>draft-ietf-bess-evpn-vpws-fxc-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9744</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9745</doc-id>
        <title>The Deprecation HTTP Response Header Field</title>
        <author>
            <name>S. Dalal</name>
        </author>
        <author>
            <name>E. Wilde</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>HTTP</kw>
            <kw>deprecation</kw>
        </keywords>
        <abstract><p>The Deprecation HTTP response header field is used to signal to consumers of a resource (identified by a URI) that the resource will be or has been deprecated.  Additionally, the deprecation link relation can be used to link to a resource that provides further information about planned or existing deprecation.  It may also provide ways in which client application developers can best manage deprecation.</p></abstract>
        <draft>draft-ietf-httpapi-deprecation-header-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>httpapi</wg_acronym>
        <doi>10.17487/RFC9745</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9746</doc-id>
        <title>BGP EVPN Multihoming Extensions for Split-Horizon Filtering</title>
        <author>
            <name>J. Rabadan</name>
        </author>
        <author>
            <name>K. Nagaraj</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>EVPN Multihoming</kw>
            <kw>Split Horizon Filtering</kw>
            <kw>Local Bias</kw>
            <kw>ESI</kw>
            <kw>encapsulations</kw>
            <kw>SHT</kw>
        </keywords>
        <abstract><p>An Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels as well as with MPLS and Segment Routing (SR) tunnels. The multihoming procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multihoming split-horizon procedures designed to prevent looped frames on multihomed Customer Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based procedure and the local-bias procedure. The ESI Label-based split-horizon procedure is applied to MPLS-based tunnels such as MPLS over UDP (MPLSoUDP), while the local-bias procedure is used for other tunnels such as Virtual eXtensible Local Area Network (VXLAN) tunnels.</p><p> Current specifications do not allow operators to choose which split-horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network Virtualization Encapsulation (Geneve), and Segment Routing over IPv6 (SRv6) tunnels. This document updates the EVPN multihoming procedures described in RFCs 7432 and 8365, enabling operators to select the split-horizon procedure that meets their specific requirements.</p></abstract>
        <draft>draft-ietf-bess-evpn-mh-split-horizon-11</draft>
        <updates>
            <doc-id>RFC7432</doc-id>
            <doc-id>RFC8365</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9746</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9747</doc-id>
        <title>Unaffiliated Bidirectional Forwarding Detection (BFD) Echo</title>
        <author>
            <name>W. Cheng</name>
        </author>
        <author>
            <name>R. Wang</name>
        </author>
        <author>
            <name>X. Min</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Rahman</name>
        </author>
        <author>
            <name>R. Boddireddy</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document specifies an extension to the Bidirectional Forwarding Detection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of forwarding path failures in networks where establishing BFD control sessions is impractical or undesirable. By decoupling the Echo function from the control plane, network devices can utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network resiliency and operational efficiency.</p><p> This document updates RFC 5880 by defining a new Unaffiliated BFD Echo mechanism.</p></abstract>
        <draft>draft-ietf-bfd-unaffiliated-echo-14</draft>
        <updates>
            <doc-id>RFC5880</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC9747</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9748</doc-id>
        <title>Updating the NTP Registries</title>
        <author>
            <name>R. Salz</name>
        </author>
        <date>
            <month>February</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>extensions</kw>
            <kw>registries</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract><p>The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries.</p><p> Some registries are correct, but some include incorrect assignments and some don't follow common practice. For the sake of completeness, this document reviews all NTP and NTS registries, and corrects the registries where necessary.</p><p> This document updates RFCs 5905, 5906, 7821, 7822, and 8573.</p></abstract>
        <draft>draft-ietf-ntp-update-registries-16</draft>
        <updates>
            <doc-id>RFC5905</doc-id>
            <doc-id>RFC5906</doc-id>
            <doc-id>RFC7821</doc-id>
            <doc-id>RFC7822</doc-id>
            <doc-id>RFC8573</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC9748</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9749</doc-id>
        <title>Use of Voluntary Application Server Identification (VAPID) in JSON Meta Application Protocol (JMAP) Web Push</title>
        <author>
            <name>D. Gultsch</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>WebPush</kw>
        </keywords>
        <abstract><p>This document defines a method for JSON Meta Application Protocol (JMAP) servers to advertise their capability to authenticate Web Push notifications using the Voluntary Application Server Identification (VAPID) protocol.</p></abstract>
        <draft>draft-ietf-jmap-webpush-vapid-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>jmap</wg_acronym>
        <doi>10.17487/RFC9749</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9750</doc-id>
        <title>The Messaging Layer Security (MLS) Architecture</title>
        <author>
            <name>B. Beurdouche</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>E. Omara</name>
        </author>
        <author>
            <name>S. Inguva</name>
        </author>
        <author>
            <name>A. Duric</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>41</page-count>
        <keywords>
            <kw>security</kw>
            <kw>authenticated key exchange</kw>
            <kw>end-to-end encryption</kw>
        </keywords>
        <abstract><p>The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS).</p><p> This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application.</p><p> While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS).</p></abstract>
        <draft>draft-ietf-mls-architecture-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>mls</wg_acronym>
        <doi>10.17487/RFC9750</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9751</doc-id>
        <title>Closing the RTP Payload Format Media Types Registry</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>The working group process and the authors of RTP payload formats have sometimes failed to ensure that the media types are registered in the IANA "RTP Payload Format Media Types" registry as recommended by RFC 8088.  To simplify the process and rely only on the "Media Types" registry, this document closes the RTP payload- specific registry.  In addition, it updates the instruction in RFC 8088 to reflect this change.</p></abstract>
        <draft>draft-ietf-avtcore-rtp-payload-registry-05</draft>
        <updates>
            <doc-id>RFC8088</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>avtcore</wg_acronym>
        <doi>10.17487/RFC9751</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9752</doc-id>
        <title>Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
        <author>
            <name>C. Li</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>S. Sivabalan</name>
        </author>
        <author>
            <name>S. Sidor</name>
        </author>
        <author>
            <name>Z. Ali</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>PCE</kw>
            <kw>vendor specific</kw>
            <kw>vendor-specific</kw>
        </keywords>
        <abstract><p>This document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) that enable the inclusion of
vendor-specific information in stateful Path Computation Element
(PCE) operations. These extensions allow vendors to incorporate
proprietary data within PCEP messages, facilitating enhanced network
optimization and functionality in environments requiring
vendor-specific features. The extensions maintain compatibility with
existing PCEP implementations and promote interoperability across
diverse network deployments. RFC 7470 defines a facility to carry
vendor-specific information in stateless PCEP messages. This document
extends this capability for the stateful PCEP messages.</p><p> This document updates RFC 7470 to specify that Enterprise Numbers are
managed through the "Private Enterprise Numbers (PENs)" registry.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-vendor-13</draft>
        <updates>
            <doc-id>RFC7470</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9752</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9753</doc-id>
        <title>Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects</title>
        <author>
            <name>C. Li</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <author>
            <name>S. Litkowski</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>PCEP</kw>
            <kw>Stateful</kw>
            <kw>optional processing</kw>
        </keywords>
        <abstract><p>This document introduces a mechanism to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange, so the stateful Path Computation Element (PCE) model can relax some constraints during path computation and setup.  This document introduces this relaxation to stateful PCE, and it updates RFC 8231.</p></abstract>
        <draft>draft-ietf-pce-stateful-pce-optional-13</draft>
        <updates>
            <doc-id>RFC8231</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9753</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9754</doc-id>
        <title>Extensions for Opening and Delegating Files in NFSv4.2</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <author>
            <name>T. Myklebust</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NFSv4</kw>
        </keywords>
        <abstract><p>The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file.  This delegation provides the client the right to authoritatively cache metadata on the file locally.  This document presents several extensions for both opening the file and delegating it to the client.  This document extends NFSv4.2 (see RFC 7863).</p></abstract>
        <draft>draft-ietf-nfsv4-delstid-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC9754</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9755</doc-id>
        <title>IMAP Support for UTF-8</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>J. Yao</name>
        </author>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <keywords>
            <kw>IMAP</kw>
        </keywords>
        <abstract><p>This specification extends the Internet Message Access Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers.  This specification replaces RFC 6855.  This specification does not extend IMAP4rev2 (RFC 9051), since that protocol includes everything in this extension.</p></abstract>
        <draft>draft-ietf-extra-6855bis-04</draft>
        <obsoletes>
            <doc-id>RFC6855</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>extra</wg_acronym>
        <doi>10.17487/RFC9755</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9756</doc-id>
        <title>Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes</title>
        <author>
            <name>D. Dhody</name>
        </author>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document updates the registration procedure within the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group. This specification changes some of the registries with Standards Action to IETF Review as defined in RFC 8126 and thus updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604.</p><p> Designating "experimental use" sub-ranges within codepoint registries is often beneficial for protocol experimentation in controlled environments. Although the registries for PCEP messages, objects, and TLV types have sub-ranges assigned for Experimental Use, the registry for PCEP Error-Types and Error-values currently does not. This document updates RFC 5440 by designating a specific range of PCEP Error-Types for Experimental Use.</p></abstract>
        <draft>draft-ietf-pce-iana-update-03</draft>
        <updates>
            <doc-id>RFC5440</doc-id>
            <doc-id>RFC8231</doc-id>
            <doc-id>RFC8233</doc-id>
            <doc-id>RFC8281</doc-id>
            <doc-id>RFC8623</doc-id>
            <doc-id>RFC8664</doc-id>
            <doc-id>RFC8685</doc-id>
            <doc-id>RFC8697</doc-id>
            <doc-id>RFC8733</doc-id>
            <doc-id>RFC8745</doc-id>
            <doc-id>RFC8779</doc-id>
            <doc-id>RFC8780</doc-id>
            <doc-id>RFC8800</doc-id>
            <doc-id>RFC8934</doc-id>
            <doc-id>RFC9050</doc-id>
            <doc-id>RFC9059</doc-id>
            <doc-id>RFC9168</doc-id>
            <doc-id>RFC9357</doc-id>
            <doc-id>RFC9504</doc-id>
            <doc-id>RFC9603</doc-id>
            <doc-id>RFC9604</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9756</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9757</doc-id>
        <title>Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks</title>
        <author>
            <name>A. Wang</name>
        </author>
        <author>
            <name>B. Khasanov</name>
        </author>
        <author>
            <name>S. Fang</name>
        </author>
        <author>
            <name>C. Zhu</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>CCDR</kw>
            <kw>PCECC</kw>
        </keywords>
        <abstract><p>This document introduces extensions to the Path Computation Element Communication Protocol (PCEP) to support path computation in Native IP networks through a PCE-based central control mechanism known as Centralized Control Dynamic Routing (CCDR).  These extensions empower a PCE to calculate and manage paths specifically for Native IP networks, thereby expanding PCEP's capabilities beyond its past use in MPLS and GMPLS networks.  By implementing these extensions, IP network resources can be utilized more efficiently, facilitating the deployment of traffic engineering in Native IP environments.</p></abstract>
        <draft>draft-ietf-pce-pcep-extension-native-ip-40</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pce</wg_acronym>
        <doi>10.17487/RFC9757</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9758</doc-id>
        <title>Updates to the 'ipn' URI Scheme</title>
        <author>
            <name>R. Taylor</name>
        </author>
        <author>
            <name>E. Birrane III</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>26</page-count>
        <keywords>
            <kw>DTN</kw>
            <kw>ipn</kw>
            <kw>BPv7</kw>
            <kw>CBHE</kw>
            <kw>Bundle Protocol</kw>
        </keywords>
        <abstract><p>This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116.  It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171.  These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme.</p></abstract>
        <draft>draft-ietf-dtn-ipn-update-14</draft>
        <updates>
            <doc-id>RFC6260</doc-id>
            <doc-id>RFC7116</doc-id>
            <doc-id>RFC9171</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>dtn</wg_acronym>
        <doi>10.17487/RFC9758</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9759</doc-id>
        <title>Unified Time Scaling for Temporal Coordination Frameworks</title>
        <author>
            <name>K. Kuhns</name>
        </author>
        <date>
            <month>April</month>
            <day>1</day>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>5</page-count>
        <keywords>
            <kw>Two-Week Principle</kw>
            <kw>TWP</kw>
        </keywords>
        <abstract><p>Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication.  Existing models fail due to inherent unpredictability and inconsistencies in human estimation.  This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration.  TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling.</p></abstract>
        <draft>draft-kkuhns-twp-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <errata-url>https://www.rfc-editor.org/errata/rfc9759</errata-url>
        <doi>10.17487/RFC9759</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9760</doc-id>
        <title>Enterprise Profile for the Precision Time Protocol with Mixed Multicast and Unicast Messages</title>
        <author>
            <name>D. Arnold</name>
        </author>
        <author>
            <name>H. Gerstung</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>PTP</kw>
            <kw>Enterprise Profile</kw>
        </keywords>
        <abstract><p>This document describes a Precision Time Protocol (PTP) Profile (IEEE Standard 1588-2019) for use in an IPv4 or IPv6 enterprise information system environment.  The PTP Profile uses the End-to-End delay measurement mechanism, allowing both multicast and unicast Delay Request and Delay Response messages.</p></abstract>
        <draft>draft-ietf-tictoc-ptp-enterprise-profile-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>tictoc</wg_acronym>
        <doi>10.17487/RFC9760</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9761</doc-id>
        <title>Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Devices</title>
        <author>
            <name>T. Reddy.K</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>B. Anderson</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <abstract><p>This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define TLS and DTLS profile parameters.  This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software, malware, or security policy-violating traffic on an endpoint.</p></abstract>
        <draft>draft-ietf-opsawg-mud-tls-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>opsawg</wg_acronym>
        <doi>10.17487/RFC9761</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9762</doc-id>
        <title>Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients</title>
        <author>
            <name>L. Colitti</name>
        </author>
        <author>
            <name>J. Linkova</name>
        </author>
        <author>
            <name>X. Ma</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Lamparter</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <keywords>
            <kw>ipv6</kw>
            <kw>slaac</kw>
            <kw>pio</kw>
            <kw>dhcpv6-pd</kw>
        </keywords>
        <abstract><p>This document defines the P flag in the Prefix Information Option (PIO) of IPv6 Router Advertisements (RAs). The flag is used to indicate that the network prefers that clients use the deployment model in RFC 9663 instead of using individual addresses in the on-link prefix assigned using Stateless Address Autoconfiguration (SLAAC) or DHCPv6 address assignment.</p><p> This document updates RFC 4862 to indicate that the Autonomous flag in a PIO needs to be ignored if the PIO has the P flag set. It also updates RFC 4861 to specify that the P flag indicates DHCPv6 prefix delegation support for clients.</p></abstract>
        <draft>draft-ietf-6man-pio-pflag-12</draft>
        <updates>
            <doc-id>RFC4861</doc-id>
            <doc-id>RFC4862</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9762</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9763</doc-id>
        <title>Related Certificates for Use in Multiple Authentications within a Protocol</title>
        <author>
            <name>A. Becker</name>
        </author>
        <author>
            <name>R. Guthrie</name>
        </author>
        <author>
            <name>M. Jenkins</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>certificate</kw>
            <kw>certificate request</kw>
            <kw>hybrid</kw>
            <kw>authentication</kw>
            <kw>post-quantum</kw>
            <kw>X.509</kw>
            <kw>digital signature</kw>
            <kw>quantum resistant</kw>
        </keywords>
        <abstract><p>This document defines a new Certificate Signing Request (CSR) attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate.  The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity.  This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms.</p></abstract>
        <draft>draft-ietf-lamps-cert-binding-for-multi-auth-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9763</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9764</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets</title>
        <author>
            <name>J. Haas</name>
        </author>
        <author>
            <name>A. Fu</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>14</page-count>
        <abstract><p>The Bidirectional Forwarding Detection (BFD) protocol is commonly
used to verify connectivity between two systems. BFD packets are
typically very small. It is desirable in some circumstances to know
not only that the path between two systems is reachable, but also
that it is capable of carrying a payload of a particular size. This
document specifies how to implement such a mechanism using BFD in
Asynchronous mode.</p><p> YANG modules for managing this mechanism are also defined in this
document. These YANG modules augment the existing BFD YANG modules
defined in RFC 9314. The YANG modules in this document conform to the
Network Management Datastore Architecture (NMDA) (RFC 8342).</p></abstract>
        <draft>draft-ietf-bfd-large-packets-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bfd</wg_acronym>
        <doi>10.17487/RFC9764</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9765</doc-id>
        <title>RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to Remove MD5</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>31</page-count>
        <keywords>
            <kw>RADIUS</kw>
            <kw>ALPN</kw>
            <kw>MD5</kw>
            <kw>FIPS 140</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract><p>This document defines Application-Layer Protocol Negotiation (ALPN) extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an application protocol variant of RADIUS called "RADIUS/1.1". No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet authentication and attribute obfuscation methods are removed.</p><p> This document updates RFCs 2865, 2866, 5176, 6613, 6614, and 7360.</p></abstract>
        <draft>draft-ietf-radext-radiusv11-11</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
            <doc-id>RFC2866</doc-id>
            <doc-id>RFC5176</doc-id>
            <doc-id>RFC6613</doc-id>
            <doc-id>RFC6614</doc-id>
            <doc-id>RFC7360</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC9765</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9766</doc-id>
        <title>Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout</title>
        <author>
            <name>T. Haynes</name>
        </author>
        <author>
            <name>T. Myklebust</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>11</page-count>
        <abstract><p>This document specifies extensions to NFSv4.2 for improving Weak Cache Consistency (WCC).  These extensions introduce mechanisms that ensure partial writes performed under a Parallel NFS (pNFS) layout remain coherent and correctly tracked.  The solution addresses concurrency and data integrity concerns that may arise when multiple clients write to the same file through separate data servers.  By defining additional interactions among clients, metadata servers, and data servers, this specification enhances the reliability of NFSv4 in parallel-access environments and ensures consistency across diverse deployment scenarios.</p></abstract>
        <draft>draft-ietf-nfsv4-layoutwcc-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>nfsv4</wg_acronym>
        <doi>10.17487/RFC9766</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9767</doc-id>
        <title>Grant Negotiation and Authorization Protocol Resource Server Connections</title>
        <author>
            <name>J. Richer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Imbault</name>
        </author>
        <date>
            <month>April</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>35</page-count>
        <abstract><p>The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software (the client) and conveying the results and artifacts of that delegation to the software.  This extension defines methods for resource servers (RSs) to connect with authorization servers (ASs) in an interoperable fashion.</p></abstract>
        <draft>draft-ietf-gnap-resource-servers-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>gnap</wg_acronym>
        <doi>10.17487/RFC9767</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9769</doc-id>
        <title>NTP Interleaved Modes</title>
        <author>
            <name>M. Lichvar</name>
        </author>
        <author>
            <name>A. Malhotra</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>NTP</kw>
            <kw>interleaved mode</kw>
        </keywords>
        <abstract><p>This document specifies interleaved modes for the Network Time Protocol (NTP).  These new modes improve the accuracy of time synchronization by enabling the use of more accurate transmit timestamps that are available only after the transmission of NTP messages.  These enhancements are intended to improve timekeeping in environments where high accuracy is critical.  This document updates RFC 5905 by defining these new operational modes.</p></abstract>
        <draft>draft-ietf-ntp-interleaved-modes-08</draft>
        <updates>
            <doc-id>RFC5905</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>ntp</wg_acronym>
        <doi>10.17487/RFC9769</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9770</doc-id>
        <title>Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
        <author>
            <name>M. Tiloca</name>
        </author>
        <author>
            <name>F. Palombini</name>
        </author>
        <author>
            <name>S. Echeverria</name>
        </author>
        <author>
            <name>G. Lewis</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>64</page-count>
        <keywords>
            <kw>Security</kw>
            <kw>Access control</kw>
            <kw>Access rights</kw>
            <kw>Revocation</kw>
            <kw>CoAP</kw>
            <kw>IoT</kw>
            <kw>Constrained environments</kw>
        </keywords>
        <abstract><p>This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens.  As specified in this document, the method allows clients and resource servers (RSs) to access a Token Revocation List (TRL) on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation.  Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and RSs.</p></abstract>
        <draft>draft-ietf-ace-revoked-token-notification-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>ace</wg_acronym>
        <doi>10.17487/RFC9770</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9771</doc-id>
        <title>Properties of Authenticated Encryption with Associated Data (AEAD) Algorithms</title>
        <author>
            <name>A. Bozhko</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>25</page-count>
        <keywords>
            <kw>authenticated encryption</kw>
            <kw>mode of operation</kw>
            <kw>AEAD</kw>
            <kw>properties</kw>
        </keywords>
        <abstract><p>Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data.  The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field.  This document provides definitions for the most common of those properties and aims to improve consistency in the terminology used in documentation.  This document is a product of the Crypto Forum Research Group.</p></abstract>
        <draft>draft-irtf-cfrg-aead-properties-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9771</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9772</doc-id>
        <title>Active Operations, Administration, and Maintenance (OAM) for Use in Generic Network Virtualization Encapsulation (Geneve)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>S. Boutros</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>S. Pallagatti</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>OAM</kw>
        </keywords>
        <abstract><p>Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensible network virtualization overlay protocol designed to encapsulate network packets for transport across underlying physical networks.  This document specifies the requirements and provides a framework for Operations, Administration, and Maintenance (OAM) in Geneve networks.  It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot Geneve overlay networks to ensure proper operation and performance.  The document aims to guide the implementation of OAM mechanisms within the Geneve protocol to support network operators in maintaining reliable and efficient virtualized network environments.</p></abstract>
        <draft>draft-ietf-nvo3-geneve-oam-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>nvo3</wg_acronym>
        <doi>10.17487/RFC9772</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9773</doc-id>
        <title>ACME Renewal Information (ARI) Extension</title>
        <author>
            <name>A. Gable</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>certificate</kw>
            <kw>CA</kw>
            <kw>x509</kw>
            <kw>pki</kw>
            <kw>webpki</kw>
            <kw>renew</kw>
            <kw>replace</kw>
        </keywords>
        <abstract><p>This document specifies how an Automated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates.  This allows servers to mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods.</p></abstract>
        <draft>draft-ietf-acme-ari-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC9773</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9774</doc-id>
        <title>Deprecation of AS_SET and AS_CONFED_SET in BGP</title>
        <author>
            <name>W. Kumari</name>
        </author>
        <author>
            <name>K. Sriram</name>
        </author>
        <author>
            <name>L. Hannachi</name>
        </author>
        <author>
            <name>J. Haas</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <abstract><p>BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP).  This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH.  This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer.  This will also simplify the design, implementation, and deployment of various BGP security mechanisms.  This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment).  Finally, it obsoletes RFC 6472.</p></abstract>
        <draft>draft-ietf-idr-deprecate-as-set-confed-set-18</draft>
        <obsoletes>
            <doc-id>RFC6472</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC4271</doc-id>
            <doc-id>RFC5065</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>idr</wg_acronym>
        <doi>10.17487/RFC9774</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9775</doc-id>
        <title>IRTF Code of Conduct</title>
        <author>
            <name>C. S. Perkins</name>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>8</page-count>
        <keywords>
            <kw>IRTF</kw>
            <kw>Code of Conduct</kw>
        </keywords>
        <abstract><p>This document describes the code of conduct for participants in the
Internet Research Task Force (IRTF).</p><p> The IRTF believes that research is most effective when done in an
open and inclusive forum that encourages diversity of ideas and
participation. Through this code of conduct, the IRTF continues to
strive to create and maintain an environment that encourages broad
participation, and one in which people are treated with dignity,
decency, and respect.</p><p> This document is a product of the Internet Research Steering Group
(IRSG).</p></abstract>
        <draft>draft-perkins-irtf-code-of-conduct-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9775</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9776</doc-id>
        <title>Internet Group Management Protocol, Version 3</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>48</page-count>
        <abstract><p>The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.</p><p> This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376.</p><p> This document updates RFC 2236 and obsoletes RFC 3376.</p></abstract>
        <draft>draft-ietf-pim-3376bis-12</draft>
        <obsoletes>
            <doc-id>RFC3376</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2236</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0100</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9776</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9777</doc-id>
        <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>56</page-count>
        <abstract><p>This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. 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.</p><p> This document updates RFC 2710 and obsoletes RFC 3810.</p></abstract>
        <draft>draft-ietf-pim-3810bis-12</draft>
        <obsoletes>
            <doc-id>RFC3810</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2710</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0101</doc-id>
        </is-also>
        <current-status>INTERNET STANDARD</current-status>
        <publication-status>INTERNET STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9777</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9778</doc-id>
        <title>IANA Considerations for Internet Group Management Protocols</title>
        <author>
            <name>B. Haberman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies revised IANA considerations for the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols.</p><p> This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols.</p></abstract>
        <draft>draft-ietf-pim-3228bis-07</draft>
        <obsoletes>
            <doc-id>RFC3228</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0057</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9778</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9779</doc-id>
        <title>Performance Measurement for Segment Routing Networks with the MPLS Data Plane</title>
        <author>
            <name>R. Gandhi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>D. Voyer</name>
        </author>
        <author>
            <name>S. Salsano</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>Delay Measurement</kw>
            <kw>Loss Measurement</kw>
            <kw>Link Measurement</kw>
            <kw>SR-MPLS Policy Measurement</kw>
        </keywords>
        <abstract><p>This document specifies the application of the MPLS loss and delay measurement techniques (originally defined in RFCs 6374, 7876, and 9341) within Segment Routing (SR) networks that utilize the MPLS data plane, also referred to as Segment Routing over MPLS (SR-MPLS).  SR enables the forwarding of packets through an ordered list of instructions, known as segments, which are imposed at the ingress node.  This document defines the procedures and extensions necessary to perform accurate measurement of packet loss and delay in SR-MPLS environments, ensuring that network operators can effectively measure and maintain the quality of service across their SR-based MPLS networks.  This includes coverage of links and end-to-end SR-MPLS paths, as well as SR Policies.</p></abstract>
        <draft>draft-ietf-mpls-rfc6374-sr-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9779</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9780</doc-id>
        <title>Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)</title>
        <author>
            <name>G. Mirsky</name>
        </author>
        <author>
            <name>G. Mishra</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>BFD</kw>
            <kw>Multipoint LSP</kw>
        </keywords>
        <abstract><p>This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in point-to-multipoint MPLS Label Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint policies with an SR over MPLS (SR-MPLS) data plane.</p><p> Furthermore, this document updates RFC 8562 by recommending the use of an IPv6 address from the Dummy IPv6 Prefix address block 100:0:0:1::/64 and discouraging the use of an IPv4 loopback address mapped to IPv6.</p><p> In addition, this document describes the applicability of LSP Ping (as an in-band solution) and the control plane (as an out-of-band solution) to bootstrap a BFD session. The document also describes the behavior of the active tail for head notification.</p></abstract>
        <draft>draft-ietf-mpls-p2mp-bfd-11</draft>
        <updates>
            <doc-id>RFC8562</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9780</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9781</doc-id>
        <title>A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)</title>
        <author>
            <name>H. Birkholz</name>
        </author>
        <author>
            <name>J. O'Donoghue</name>
        </author>
        <author>
            <name>N. Cam-Winget</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>16</page-count>
        <keywords>
            <kw>Secure Channel</kw>
            <kw>RATS</kw>
            <kw>Conceptual Message Conveyance</kw>
            <kw>Privacy</kw>
            <kw>Confidentiality</kw>
            <kw>CDDL</kw>
            <kw>EAT</kw>
            <kw>UJCS</kw>
        </keywords>
        <abstract><p>This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, Message Authentication Code (MAC), or encryption.  UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments.  This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and its processing considerations.  It also discusses security implications of using unprotected claims sets.</p></abstract>
        <draft>draft-ietf-rats-uccs-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>rats</wg_acronym>
        <doi>10.17487/RFC9781</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9782</doc-id>
        <title>Entity Attestation Token (EAT) Media Types</title>
        <author>
            <name>L. Lundblade</name>
        </author>
        <author>
            <name>H. Birkholz</name>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <date>
            <month>May</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>EAT</kw>
            <kw>media type</kw>
        </keywords>
        <abstract><p>The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs.</p><p> This memo defines media types to be used for Entity Attestation Tokens (EATs).</p></abstract>
        <draft>draft-ietf-rats-eat-media-type-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>rats</wg_acronym>
        <doi>10.17487/RFC9782</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9783</doc-id>
        <title>Arm's Platform Security Architecture (PSA) Attestation Token</title>
        <author>
            <name>H. Tschofenig</name>
        </author>
        <author>
            <name>S. Frost</name>
        </author>
        <author>
            <name>M. Brossard</name>
        </author>
        <author>
            <name>A. Shaw</name>
        </author>
        <author>
            <name>T. Fossati</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>36</page-count>
        <keywords>
            <kw>Remote Attestation</kw>
            <kw>EAT profile</kw>
            <kw>Evidence</kw>
            <kw>RATS</kw>
            <kw>IoT</kw>
        </keywords>
        <abstract><p>Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token.</p><p> The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected.</p><p> This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF.</p></abstract>
        <draft>draft-tschofenig-rats-psa-token-24</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>INDEPENDENT</stream>
        <doi>10.17487/RFC9783</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9784</doc-id>
        <title>Virtual Ethernet Segments for EVPN and Provider Backbone Bridge EVPN</title>
        <author>
            <name>A. Sajassi</name>
        </author>
        <author>
            <name>P. Brissette</name>
        </author>
        <author>
            <name>R. Schell</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <keywords>
            <kw>vES</kw>
            <kw>Virtual ES</kw>
        </keywords>
        <abstract><p>Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks.  These solutions offer advanced multihoming capabilities.  Specifically, they support Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multihomed device or network to a set of Provider Edge (PE) devices.  This document extends the concept of an ES by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs), such as VLANs, or other entities, including MPLS Label Switched Paths (LSPs) or pseudowires (PWs).  This extended concept is referred to as virtual Ethernet Segments (vESes).  This document lists the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN.</p></abstract>
        <draft>draft-ietf-bess-evpn-virtual-eth-segment-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9784</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9785</doc-id>
        <title>Preference-Based EVPN Designated Forwarder (DF) Election</title>
        <author>
            <name>J. Rabadan</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Sathappan</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <author>
            <name>J. Drake</name>
        </author>
        <author>
            <name>A. Sajassi</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>Highest-Preference</kw>
            <kw>Lowest-Preference</kw>
            <kw>Non-Revertive</kw>
            <kw>Don’t Preempt</kw>
            <kw>Preemption</kw>
        </keywords>
        <abstract><p>The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPNs) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device/network in the case of an All-Active multihoming Ethernet Segment (ES) or BUM and unicast in the case of Single-Active multihoming. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the default DF election algorithm. While the default algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more "deterministic" and user-controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE.</p><p> This document proposes use of a DF election algorithm that meets the requirements of determinism and operation control. This document updates RFC 8584 by modifying the definition of the DF Election Extended Community.</p></abstract>
        <draft>draft-ietf-bess-evpn-pref-df-13</draft>
        <updates>
            <doc-id>RFC8584</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9785</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9786</doc-id>
        <title>EVPN Port-Active Redundancy Mode</title>
        <author>
            <name>P. Brissette</name>
        </author>
        <author>
            <name>LA. Burdet</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Wen</name>
        </author>
        <author>
            <name>E. Leyton</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Port-Active</kw>
            <kw>EVPN</kw>
            <kw>Multihoming</kw>
        </keywords>
        <abstract><p>The Multi-Chassis Link Aggregation (MC-LAG) group technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes.  The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of traffic load balancing.  RFC 7432 defines an EVPN-based MC-LAG with Single-Active and All-Active multihoming redundancy modes.  This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'.</p></abstract>
        <draft>draft-ietf-bess-evpn-mh-pa-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9786</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9789</doc-id>
        <title>MPLS Network Actions (MNAs) Framework</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>19</page-count>
        <keywords>
            <kw>network function virtualization</kw>
            <kw>service chaining</kw>
        </keywords>
        <abstract><p>This document describes an architectural framework for MPLS Network Action (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet and to transfer any additional data needed for these actions.</p><p> This document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks.</p></abstract>
        <draft>draft-ietf-mpls-mna-fwk-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9789</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9790</doc-id>
        <title>IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>S. Bryant</name>
        </author>
        <author>
            <name>M. Bocci</name>
        </author>
        <author>
            <name>G. Mirsky</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>Post-stack header</kw>
            <kw>Load-balancing</kw>
        </keywords>
        <abstract><p>This document creates a new IANA registry (called the "Post-Stack First Nibble" registry) for the first nibble (4-bit field) immediately following an MPLS label stack. Furthermore, this document presents some requirements for registering new values and making the processing of MPLS packets easier and more robust.</p><p> The relationship between the IANA "Post-Stack First Nibble" registry and the "IP Version Numbers" registry (RFC 2780) is described in this document.</p><p> This document updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS.</p></abstract>
        <draft>draft-ietf-mpls-1stnibble-13</draft>
        <updates>
            <doc-id>RFC4928</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9790</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9791</doc-id>
        <title>Use Cases for MPLS Network Action Indicators and Ancillary Data</title>
        <author>
            <name>T. Saad</name>
        </author>
        <author>
            <name>K. Makhijani</name>
        </author>
        <author>
            <name>H. Song</name>
        </author>
        <author>
            <name>G. Mirsky</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Special Purpose Label</kw>
            <kw>MPLS data plane</kw>
        </keywords>
        <abstract><p>This document presents use cases that have a common feature that may be addressed by encoding network action indicators and associated ancillary data within MPLS packets. There is community interest in extending the MPLS data plane to carry such indicators and ancillary data to address these use cases.</p><p> The use cases described in this document are not an exhaustive set but rather the ones that have been actively discussed by members of the IETF MPLS, PALS, and DetNet Working Groups from the beginning of work on MPLS Network Action (MNA) until the publication of this document.</p></abstract>
        <draft>draft-ietf-mpls-mna-usecases-15</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>mpls</wg_acronym>
        <doi>10.17487/RFC9791</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9792</doc-id>
        <title>Prefix Flag Extension for OSPFv2 and OSPFv3</title>
        <author>
            <name>R. Chen</name>
        </author>
        <author>
            <name>D. Zhao</name>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <author>
            <name>L. Gong</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>Prefix attributes</kw>
            <kw>IGP</kw>
        </keywords>
        <abstract><p>Each OSPF prefix can be advertised with an 8-bit field to indicate specific properties of that prefix. However, all the OSPFv3 Prefix Options bits have already been assigned, and only a few bits remain unassigned in the Flags field of the OSPFv2 Extended Prefix TLV.</p><p> This document solves this problem by defining a variable-length Prefix Extended Flags sub-TLV for OSPF. This sub-TLV is applicable to OSPFv2 and OSPFv3.</p></abstract>
        <draft>draft-ietf-lsr-ospf-prefix-extended-flags-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9792</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9793</doc-id>
        <title>BGP Extensions for Bit Index Explicit Replication (BIER)</title>
        <author>
            <name>X. Xu</name>
        </author>
        <author>
            <name>M. Chen</name>
        </author>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>IJ. Wijnands</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>Z. Zhang</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>Bit Index Explicit Replication (BIER) is a multicast forwarding architecture that doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain per-tree multicast states.  Some BIER-specific information and states, which are only in proportion to the number of BIER routers but not per-tree, do need to be advertised, calculated, and maintained.  This document describes BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisements.</p></abstract>
        <draft>draft-ietf-bier-idr-extensions-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bier</wg_acronym>
        <errata-url>https://www.rfc-editor.org/errata/rfc9793</errata-url>
        <doi>10.17487/RFC9793</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9794</doc-id>
        <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
        <author>
            <name>F. Driscoll</name>
        </author>
        <author>
            <name>M. Parsons</name>
        </author>
        <author>
            <name>B. Hale</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <keywords>
            <kw>cryptography</kw>
            <kw>quantum-safe</kw>
            <kw>pqc</kw>
            <kw>composite</kw>
        </keywords>
        <abstract><p>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms.  This document defines terminology for such schemes.  It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</p></abstract>
        <draft>draft-ietf-pquip-pqt-hybrid-terminology-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>pquip</wg_acronym>
        <doi>10.17487/RFC9794</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9795</doc-id>
        <title>Personal Assertion Token (PASSporT) Extension for Rich Call Data</title>
        <author>
            <name>C. Wendt</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Identity</kw>
        </keywords>
        <abstract><p>This document extends Personal Assertion Token (PASSporT), a token for conveying cryptographically signed call information about personal communications, to include rich metadata about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party.  This framework is intended to include and extend caller- and call-specific information beyond human-readable display name, comparable to the "Caller ID" function common on the telephone network.  It is also enhanced with an integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use cases.</p></abstract>
        <draft>draft-ietf-stir-passport-rcd-26</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>stir</wg_acronym>
        <doi>10.17487/RFC9795</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9796</doc-id>
        <title>SIP Call-Info Parameters for Rich Call Data</title>
        <author>
            <name>C. Wendt</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>29</page-count>
        <keywords>
            <kw>Identity</kw>
        </keywords>
        <abstract><p>This document specifies a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the originating party in order to provide to the terminating party a description of the caller (including details about the reason for the session). RCD includes information about the caller beyond the telephone number (such as a calling name, logo, photo, or jCard object representing the caller), which can help the called party decide how to handle the session request.</p><p> This document defines three new parameters 'call-reason', 'verified', and 'integrity' for the SIP Call-Info header field and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon".</p></abstract>
        <draft>draft-ietf-sipcore-callinfo-rcd-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC9796</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9797</doc-id>
        <title>Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases</title>
        <author>
            <name>J. Henry</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>17</page-count>
        <keywords>
            <kw>RCM</kw>
            <kw>Universal MAC address</kw>
            <kw>Local MAC address</kw>
            <kw>Locally Administered MAC address</kw>
            <kw>Personal Device</kw>
            <kw>Shared Service Device</kw>
            <kw>Network Functional Entities</kw>
            <kw>Human-Related Entities</kw>
            <kw>Over-the-Air (OTA) observers</kw>
            <kw>Wireless access network operators</kw>
            <kw>Network access providers</kw>
            <kw>Over-the-Wired internal (OTWi) observers</kw>
            <kw>Over-the-Wired external (OTWe) observers</kw>
            <kw>full trust</kw>
            <kw>selective trust</kw>
            <kw>zero trust</kw>
            <kw>privacy</kw>
            <kw>Residential settings</kw>
            <kw>Managed residential settings</kw>
            <kw>public guest network</kw>
            <kw>Enterprises with Bring-Your-Own-Device (BYOD)</kw>
            <kw>Managed Enterprises</kw>
        </keywords>
        <abstract><p>To limit the privacy issues created by the association between a device, its traffic, its location, and its user in IEEE 802 networks, client vendors and client OS vendors have started implementing Media Access Control (MAC) address randomization. This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the purpose of MAC address randomization.</p><p> This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines some existing frameworks that maintain user privacy while preserving user quality of experience and network operation efficiency.</p></abstract>
        <draft>draft-ietf-madinas-use-cases-19</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>madinas</wg_acronym>
        <doi>10.17487/RFC9797</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9798</doc-id>
        <title>PIM Join/Prune Attributes for Locator/ID Separation Protocol (LISP) Environments Using Underlay Multicast</title>
        <author>
            <name>V. Govindan</name>
        </author>
        <author>
            <name>S. Venaas</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>6</page-count>
        <abstract><p>This document specifies an update to the Receiver RLOC (Routing Locator) field of the PIM Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP multicast.  This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR).  This document updates RFC 8059.</p></abstract>
        <draft>draft-ietf-pim-jp-extensions-lisp-09</draft>
        <updates>
            <doc-id>RFC8059</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pim</wg_acronym>
        <doi>10.17487/RFC9798</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9799</doc-id>
        <title>Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names</title>
        <author>
            <name>Q Misell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>tor</kw>
            <kw>hidden service</kw>
            <kw>onion service</kw>
            <kw>caa</kw>
            <kw>dns</kw>
        </keywords>
        <abstract><p>This document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor Hidden Services (".onion" Special-Use Domain Names).</p></abstract>
        <draft>draft-ietf-acme-onion-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>acme</wg_acronym>
        <doi>10.17487/RFC9799</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9800</doc-id>
        <title>Compressed SRv6 Segment List Encoding</title>
        <author>
            <name>W. Cheng</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Filsfils</name>
        </author>
        <author>
            <name>Z. Li</name>
        </author>
        <author>
            <name>B. Decraene</name>
        </author>
        <author>
            <name>F. Clad</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>59</page-count>
        <keywords>
            <kw>Segment Routing</kw>
            <kw>IPv6 Segment Routing</kw>
            <kw>Compressed SID</kw>
            <kw>CSID</kw>
            <kw>NEXT-CSID</kw>
            <kw>REPLACE-SID</kw>
            <kw>SRH Compression</kw>
        </keywords>
        <abstract><p>Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.</p><p> This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document.</p></abstract>
        <draft>draft-ietf-spring-srv6-srh-compression-23</draft>
        <updates>
            <doc-id>RFC8754</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>spring</wg_acronym>
        <doi>10.17487/RFC9800</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9801</doc-id>
        <title>Private Line Emulation over Packet Switched Networks</title>
        <author>
            <name>S. Gringeri</name>
        </author>
        <author>
            <name>J. Whittaker</name>
        </author>
        <author>
            <name>N. Leymann</name>
        </author>
        <author>
            <name>C. Schmutzer</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Brown</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>pseudowires</kw>
            <kw>circuit emulation</kw>
            <kw>structure-agnostic emulation</kw>
            <kw>bit-stream payload</kw>
            <kw>SR-MPLS</kw>
            <kw>SRv6</kw>
            <kw>IWF</kw>
        </keywords>
        <abstract><p>This document expands the applicability of Virtual Private Wire Service (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over Packet Switched Networks (PSNs).</p></abstract>
        <draft>draft-ietf-pals-ple-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>pals</wg_acronym>
        <doi>10.17487/RFC9801</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9802</doc-id>
        <title>Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure</title>
        <author>
            <name>D. Van Geest</name>
        </author>
        <author>
            <name>K. Bashiri</name>
        </author>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <author>
            <name>S. Gazdag</name>
        </author>
        <author>
            <name>S. Kousidis</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>30</page-count>
        <keywords>
            <kw>HSS</kw>
            <kw>LMS</kw>
            <kw>XMSS</kw>
            <kw>certificate</kw>
            <kw>X.509</kw>
            <kw>PKIX</kw>
            <kw>stateful</kw>
            <kw>hash-based</kw>
        </keywords>
        <abstract><p>This document specifies algorithm identifiers and ASN.1 encoding formats for the following stateful Hash-Based Signature (HBS) schemes: Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS).  This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs).</p></abstract>
        <draft>draft-ietf-lamps-x509-shbs-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9802</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9803</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live (TTL) Values</title>
        <author>
            <name>G. Brown</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>24</page-count>
        <keywords>
            <kw>EPP</kw>
            <kw>DNS</kw>
            <kw>TTL</kw>
            <kw>time-to-live</kw>
        </keywords>
        <abstract><p>This document describes an extension to the Extensible Provisioning
Protocol (EPP) that allows EPP clients to manage the Time-to-Live
(TTL) value for domain name delegation records.</p></abstract>
        <draft>draft-ietf-regext-epp-ttl-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>regext</wg_acronym>
        <doi>10.17487/RFC9803</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9804</doc-id>
        <title>Simple Public Key Infrastructure (SPKI) S-Expressions</title>
        <author>
            <name>R. Rivest</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>22</page-count>
        <keywords>
            <kw>Sexp</kw>
            <kw>Sexpression</kw>
            <kw>S-expression</kw>
        </keywords>
        <abstract><p>This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI) certificates, as detailed in RFC 2692, with the intent that it be more widely applicable.  It has been and is being used elsewhere.  There are multiple implementations in a variety of programming languages.  Uses of this representation are referred to in this document as "S-expressions".  This memo makes precise the encodings of these SPKI S-expressions: It gives a "canonical form" for them, describes two "transport" representations, and also describes an "advanced" format for display to people.</p></abstract>
        <draft>draft-rivest-sexp-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <wg_acronym>NON WORKING GROUP</wg_acronym>
        <doi>10.17487/RFC9804</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9805</doc-id>
        <title>Deprecation of the IPv6 Router Alert Option for New Protocols</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6</kw>
        </keywords>
        <abstract><p>This document deprecates the IPv6 Router Alert option. Protocols that use the IPv6 Router Alert option may continue to do so, even in future versions. However, new protocols that are standardized in the future must not use the IPv6 Router Alert option.</p><p> This document updates RFC 2711.</p></abstract>
        <draft>draft-ietf-6man-deprecate-router-alert-13</draft>
        <updates>
            <doc-id>RFC2711</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>int</area>
        <wg_acronym>6man</wg_acronym>
        <doi>10.17487/RFC9805</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9806</doc-id>
        <title>Updates to SIP-Based Media Recording (SIPREC) to Correct Metadata Media Type</title>
        <author>
            <name>D. Mongrain</name>
        </author>
        <date>
            <month>June</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>4</page-count>
        <keywords>
            <kw>siprec</kw>
            <kw>errata</kw>
        </keywords>
        <abstract><p>The SIP-based Media Recording (SIPREC) protocol is defined by both "Session Initiation Protocol (SIP) Recording Metadata" (RFC 7865) and "Session Recording Protocol" (RFC 7866).  Unfortunately, both RFCs contradict each other regarding how recording metadata is to be labeled.  In addition, neither RFC registered the new media type.  This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and also registers the media type.</p></abstract>
        <draft>draft-ietf-sipcore-siprec-fix-mediatype-06</draft>
        <updates>
            <doc-id>RFC7866</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>art</area>
        <wg_acronym>sipcore</wg_acronym>
        <doi>10.17487/RFC9806</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9807</doc-id>
        <title>The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE) Protocol</title>
        <author>
            <name>D. Bourdrez</name>
        </author>
        <author>
            <name>H. Krawczyk</name>
        </author>
        <author>
            <name>K. Lewi</name>
        </author>
        <author>
            <name>C. A. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>73</page-count>
        <abstract><p>This document describes the OPAQUE protocol, an Augmented (or Asymmetric) Password-Authenticated Key Exchange (aPAKE) protocol that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise.  In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration.  This document specifies the core OPAQUE protocol and one instantiation based on 3DH.  This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</p></abstract>
        <draft>draft-irtf-cfrg-opaque-18</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IRTF</stream>
        <doi>10.17487/RFC9807</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9808</doc-id>
        <title>Content Delivery Network Interconnection (CDNI) Capacity Capability Advertisement Extensions</title>
        <author>
            <name>A. Ryan</name>
        </author>
        <author>
            <name>B. Rosenblum</name>
        </author>
        <author>
            <name>N. Sopher</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>15</page-count>
        <abstract><p>This specification defines a set of additional Capability Objects that provide information about current downstream CDN (dCDN) utilization and specified usage limits to the delegating upstream CDN (uCDN) in order to inform traffic delegation decisions.</p><p> This document supplements the CDNI Capability Objects, defined in RFC 8008 as part of the Footprint &amp; Capabilities Advertisement Interface (FCI), with two additional Capability Objects: FCI.CapacityLimits and FCI.Telemetry.</p></abstract>
        <draft>draft-ietf-cdni-capacity-insights-extensions-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>wit</area>
        <wg_acronym>cdni</wg_acronym>
        <doi>10.17487/RFC9808</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9809</doc-id>
        <title>X.509 Certificate Extended Key Usage (EKU) for Configuration, Updates, and Safety-Critical Communication</title>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <author>
            <name>D. Goltzsche</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <keywords>
            <kw>Industrial Automation</kw>
            <kw>ERJU</kw>
            <kw>extended key usage</kw>
            <kw>extension</kw>
            <kw>PKI</kw>
        </keywords>
        <abstract><p>RFC 5280 defines the Extended Key Usage (EKU) extension and specifies several extended key purpose identifiers (KeyPurposeIds) for use with that extension in X.509 certificates.  This document defines KeyPurposeIds for general-purpose and trust anchor configuration files, for software and firmware update packages, and for safety-critical communication to be included in the EKU extension of X.509 v3 public key certificates.</p></abstract>
        <draft>draft-ietf-lamps-automation-keyusages-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9809</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9810</doc-id>
        <title>Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)</title>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <author>
            <name>D. von Oheimb</name>
        </author>
        <author>
            <name>M. Ounsworth</name>
        </author>
        <author>
            <name>J. Gray</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>116</page-count>
        <keywords>
            <kw>CMP</kw>
            <kw>HTTP</kw>
            <kw>Certificate management</kw>
            <kw>PKI</kw>
        </keywords>
        <abstract><p>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA).</p><p> This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480.</p><p> This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912.</p></abstract>
        <draft>draft-ietf-lamps-rfc4210bis-18</draft>
        <obsoletes>
            <doc-id>RFC4210</doc-id>
            <doc-id>RFC9480</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC5912</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9810</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9811</doc-id>
        <title>Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)</title>
        <author>
            <name>H. Brockhaus</name>
        </author>
        <author>
            <name>D. von Oheimb</name>
        </author>
        <author>
            <name>M. Ounsworth</name>
        </author>
        <author>
            <name>J. Gray</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>10</page-count>
        <keywords>
            <kw>CMP</kw>
            <kw>HTTP</kw>
            <kw>Certificate management</kw>
            <kw>PKI</kw>
        </keywords>
        <abstract><p>This document describes how to layer the Certificate Management Protocol (CMP) over HTTP.</p><p> It includes the updates to RFC 6712 specified in Section 3 of RFC 9480; these updates introduce CMP URIs using a well-known prefix. It obsoletes RFC 6712; and, together with RFC 9810, it also obsoletes RFC 9480.</p></abstract>
        <draft>draft-ietf-lamps-rfc6712bis-10</draft>
        <obsoletes>
            <doc-id>RFC6712</doc-id>
            <doc-id>RFC9480</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9811</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9813</doc-id>
        <title>Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS</title>
        <author>
            <name>A. DeKok</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>20</page-count>
        <abstract><p>This document provides implementation and operational considerations for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RADIUS/DTLS (RFC 7360).  The purpose of the document is to help smooth the operational transition from the use of RADIUS/UDP to RADIUS/TLS.</p></abstract>
        <draft>draft-ietf-radext-tls-psk-12</draft>
        <is-also>
            <doc-id>BCP0243</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>radext</wg_acronym>
        <doi>10.17487/RFC9813</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9814</doc-id>
        <title>Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Fluhrer</name>
        </author>
        <author>
            <name>P. Kampanakis</name>
        </author>
        <author>
            <name>B. Westerbaan</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <keywords>
            <kw>stateless hash-based signature algorithm</kw>
        </keywords>
        <abstract><p>SLH-DSA is a stateless hash-based signature algorithm.  This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS).  In addition, the algorithm identifier and public key syntax are provided.</p></abstract>
        <draft>draft-ietf-lamps-cms-sphincs-plus-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>sec</area>
        <wg_acronym>lamps</wg_acronym>
        <doi>10.17487/RFC9814</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9815</doc-id>
        <title>BGP Link State (BGP-LS) Shortest Path First (SPF) Routing</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>S. Zandi</name>
        </author>
        <author>
            <name>W. Henderickx</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>33</page-count>
        <keywords>
            <kw>IDR</kw>
        </keywords>
        <abstract><p>Many Massively Scaled Data Centers (MSDCs) have converged on simplified Layer 3 (L3) routing.  Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both fabric routing and Data Center Interconnect (DCI) routing.  This document describes extensions to BGP for use with BGP Link State (BGP-LS) distribution and the Shortest Path First (SPF) algorithm.  In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs.</p></abstract>
        <draft>draft-ietf-lsvr-bgp-spf-51</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsvr</wg_acronym>
        <doi>10.17487/RFC9815</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9816</doc-id>
        <title>Usage and Applicability of BGP Link State (BGP-LS) Shortest Path First (SPF) Routing in Data Centers</title>
        <author>
            <name>K. Patel</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>S. Zandi</name>
        </author>
        <author>
            <name>G. Dawra</name>
        </author>
        <author>
            <name>J. Dong</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>12</page-count>
        <abstract><p>This document discusses the usage and applicability of BGP Link State (BGP-LS) Shortest Path First (SPF) extensions in data center networks utilizing Clos or Fat Tree topologies.  The document is intended to provide simplified guidance for the deployment of BGP-LS SPF extensions.</p></abstract>
        <draft>draft-ietf-lsvr-applicability-22</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsvr</wg_acronym>
        <doi>10.17487/RFC9816</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9818</doc-id>
        <title>DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs</title>
        <author>
            <name>T. Winters</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>IPv6</kw>
            <kw>Internet Protocol Version 6</kw>
            <kw>DHCPv6</kw>
        </keywords>
        <abstract><p>This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes to LAN devices that were delegated to an IPv6 CE router.  This document updates RFC 7084.</p></abstract>
        <draft>draft-ietf-v6ops-cpe-lan-pd-09</draft>
        <updates>
            <doc-id>RFC7084</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>v6ops</wg_acronym>
        <doi>10.17487/RFC9818</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9819</doc-id>
        <title>Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)</title>
        <author>
            <name>K. Talaulikar</name>
        </author>
        <author>
            <name>K. Raza</name>
        </author>
        <author>
            <name>J. Rabadan</name>
        </author>
        <author>
            <name>W. Lin</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>13</page-count>
        <keywords>
            <kw>BGP</kw>
            <kw>SRv6</kw>
        </keywords>
        <abstract><p>RFC 9252 defines procedures and messages for BGP overlay services for Segment Routing over IPv6 (SRv6), including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and global Internet routing.  This document updates RFC 9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifier advertisements for BGP overlay service routes associated with SRv6 Endpoint Behaviors that support arguments.</p></abstract>
        <draft>draft-ietf-bess-bgp-srv6-args-10</draft>
        <updates>
            <doc-id>RFC9252</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>bess</wg_acronym>
        <doi>10.17487/RFC9819</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9825</doc-id>
        <title>Extensions to OSPF for Advertising Prefix Administrative Tags</title>
        <author>
            <name>A. Lindem</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Psenak</name>
        </author>
        <author>
            <name>Y. Qu</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>18</page-count>
        <abstract><p>It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes.  Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS) External and Not-So-Stubby-Area (NSSA) prefixes.  With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative tags may be advertised for all types of prefixes.  These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast Reroute (IPFRR) prefix protection, and many others.</p></abstract>
        <draft>draft-ietf-lsr-ospf-admin-tags-29</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>rtg</area>
        <wg_acronym>lsr</wg_acronym>
        <doi>10.17487/RFC9825</doi>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC9829</doc-id>
        <title>Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions</title>
        <author>
            <name>J. Snijders</name>
        </author>
        <author>
            <name>B. Maddison</name>
        </author>
        <author>
            <name>T. Buehler</name>
        </author>
        <date>
            <month>July</month>
            <year>2025</year>
        </date>
        <format>
            <file-format>HTML</file-format>
            <file-format>TEXT</file-format>
            <file-format>PDF</file-format>
            <file-format>XML</file-format>
        </format>
        <page-count>7</page-count>
        <keywords>
            <kw>RPKI</kw>
            <kw>Routing Security</kw>
            <kw>BGP</kw>
            <kw>X.509</kw>
            <kw>CRL</kw>
        </keywords>
        <abstract><p>This document revises how the Resource Public Key Infrastructure (RPKI) handles Certificate Revocation List (CRL) Number extensions.  This document updates RFC 6487.</p></abstract>
        <draft>draft-ietf-sidrops-rpki-crl-numbers-05</draft>
        <updates>
            <doc-id>RFC6487</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
        <stream>IETF</stream>
        <area>ops</area>
        <wg_acronym>sidrops</wg_acronym>
        <doi>10.17487/RFC9829</doi>
    </rfc-entry>
    <std-entry>
        <doc-id>STD0001</doc-id>
        <title>[STD number 1 is retired. It was "Internet Official Protocol Standards".  See BCP 9 / RFC 7100 for more information.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0002</doc-id>
        <title>[Reserved for Assigned Numbers. See RFC 1700 and RFC 3232.]</title>
    </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 (TCP)</title>
        <is-also>
            <doc-id>RFC9293</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>RFC0974</doc-id>
            <doc-id>RFC1869</doc-id>
            <doc-id>RFC1870</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 for Network Management of TCP/IP-based internets: MIB-II</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</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 Protocol</title>
        <is-also>
            <doc-id>RFC0868</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0027</doc-id>
        <title>Telnet Binary Transmission</title>
        <is-also>
            <doc-id>RFC0856</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0028</doc-id>
        <title>Telnet Echo Option</title>
        <is-also>
            <doc-id>RFC0857</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0029</doc-id>
        <title>Telnet Suppress Go Ahead Option</title>
        <is-also>
            <doc-id>RFC0858</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0030</doc-id>
        <title>Telnet Status Option</title>
        <is-also>
            <doc-id>RFC0859</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0031</doc-id>
        <title>Telnet Timing Mark Option</title>
        <is-also>
            <doc-id>RFC0860</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0032</doc-id>
        <title>Telnet Extended Options: List Option</title>
        <is-also>
            <doc-id>RFC0861</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0033</doc-id>
        <title>The TFTP Protocol (Revision 2)</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: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware</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>A 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 Ethernet networks</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>
    <std-entry>
        <doc-id>STD0067</doc-id>
        <title>XDR: External Data Representation Standard</title>
        <is-also>
            <doc-id>RFC4506</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0068</doc-id>
        <title>Augmented BNF for Syntax Specifications: ABNF</title>
        <is-also>
            <doc-id>RFC5234</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0069</doc-id>
        <title>The Extensible Provisioning Protocol (EPP)</title>
        <is-also>
            <doc-id>RFC5730</doc-id>
            <doc-id>RFC5731</doc-id>
            <doc-id>RFC5732</doc-id>
            <doc-id>RFC5733</doc-id>
            <doc-id>RFC5734</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0070</doc-id>
        <title>Cryptographic Message Syntax (CMS)</title>
        <is-also>
            <doc-id>RFC5652</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0071</doc-id>
        <title>SMTP Service Extension for 8-bit MIME Transport</title>
        <is-also>
            <doc-id>RFC6152</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0072</doc-id>
        <title>Message Submission for Mail</title>
        <is-also>
            <doc-id>RFC6409</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0073</doc-id>
        <title>The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages</title>
        <is-also>
            <doc-id>RFC6522</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0074</doc-id>
        <title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title>
        <is-also>
            <doc-id>RFC5011</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0075</doc-id>
        <title>Extension Mechanisms for DNS (EDNS(0))</title>
        <is-also>
            <doc-id>RFC6891</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0076</doc-id>
        <title>DomainKeys Identified Mail (DKIM) Signatures</title>
        <is-also>
            <doc-id>RFC6376</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0077</doc-id>
        <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
        <is-also>
            <doc-id>RFC7011</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0078</doc-id>
        <title>Simple Network Management Protocol (SNMP) Security</title>
        <is-also>
            <doc-id>RFC5343</doc-id>
            <doc-id>RFC5590</doc-id>
            <doc-id>RFC5591</doc-id>
            <doc-id>RFC6353</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0079</doc-id>
        <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
        <is-also>
            <doc-id>RFC7296</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0080</doc-id>
        <title>ASCII format for network interchange</title>
        <is-also>
            <doc-id>RFC0020</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0081</doc-id>
        <title>A One-Way Delay Metric for IP Performance Metrics (IPPM)</title>
        <is-also>
            <doc-id>RFC7679</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0082</doc-id>
        <title>A One-Way Loss Metric for IP Performance Metrics (IPPM)</title>
        <is-also>
            <doc-id>RFC7680</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0083</doc-id>
        <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
        <is-also>
            <doc-id>RFC7761</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0084</doc-id>
        <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
        <is-also>
            <doc-id>RFC8077</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0085</doc-id>
        <title>Message Disposition Notification</title>
        <is-also>
            <doc-id>RFC8098</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0086</doc-id>
        <title>Internet Protocol, Version 6 (IPv6) Specification</title>
        <is-also>
            <doc-id>RFC8200</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0087</doc-id>
        <title>Path MTU Discovery for IP version 6</title>
        <is-also>
            <doc-id>RFC8201</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0088</doc-id>
        <title>DNS Extensions to Support IP Version 6</title>
        <is-also>
            <doc-id>RFC3596</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0089</doc-id>
        <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
        <is-also>
            <doc-id>RFC4443</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0090</doc-id>
        <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
        <is-also>
            <doc-id>RFC8259</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0091</doc-id>
        <title>Network Configuration Access Control Model</title>
        <is-also>
            <doc-id>RFC8341</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0092</doc-id>
        <title>Internet Printing Protocol/1.1</title>
        <is-also>
            <doc-id>RFC8010</doc-id>
            <doc-id>RFC8011</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0093</doc-id>
        <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
        <is-also>
            <doc-id>RFC8945</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0094</doc-id>
        <title>Concise Binary Object Representation (CBOR)</title>
        <is-also>
            <doc-id>RFC8949</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0095</doc-id>
        <title>RDAP</title>
        <is-also>
            <doc-id>RFC7480</doc-id>
            <doc-id>RFC7481</doc-id>
            <doc-id>RFC9082</doc-id>
            <doc-id>RFC9083</doc-id>
            <doc-id>RFC9224</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0096</doc-id>
        <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
        <is-also>
            <doc-id>RFC9052</doc-id>
            <doc-id>RFC9338</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0097</doc-id>
        <title>HTTP Semantics</title>
        <is-also>
            <doc-id>RFC9110</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0098</doc-id>
        <title>HTTP Caching</title>
        <is-also>
            <doc-id>RFC9111</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0099</doc-id>
        <title>HTTP/1.1</title>
        <is-also>
            <doc-id>RFC9112</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0100</doc-id>
        <title>Internet Group Management Protocol, Version 3</title>
        <is-also>
            <doc-id>RFC9776</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0101</doc-id>
        <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
        <is-also>
            <doc-id>RFC9777</doc-id>
        </is-also>
    </std-entry>
</rfc-index>
